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The  purpose  of  this  study  was  to  develop  a  computer  aided  design  (CAD)  tool  to 
supplement  instructicMi  in  computer  communications  networks.  There  existed  a  need  for 
computer  aided  modeling  and  analysis  of  user-defined  networks  and  this  work  was 
dedicated  to  that  purpose. 

Most  of  the  effort  was  concentrated  on  providing  a  graphical  interface  between 
human  and  machine  with  the  ultimate  goal  of  making  the  operation  of  the  tool  as  transparent 
as  possible.  Although  extensive  testing  was  done  during  the  development,  the  ultimate  test 
will  be  whether  or  not  the  software  helps  the  student  understand  concepts  presented  in 
textbooks  and  lecture. 

I  would  like  to  acknowledge  some  of  the  individuals  who  helped  make  this  work 
possible.  First  of  all.  I'd  like  to  thank  my  thesis  advisor,  Capt  George,  for  providing 
direction,  encouragement,  and  perhaps  most  of  all,  a  positive  attitude.  I  also  wish  to  thank 
LTC  Garcia  for  the  use  of  his  ctnnputer  network  class  in  beta  testing  the  software.  Thanks 
go  also  to  my  ccmmittee  members,  Capt  Davis  and  Capt  Fautheree.  I^ally,  I  wish  to 
express  my  profound  gratitude  to  my  wife  Haeng  Soon  for  her  tolerance,  patience,  and 
moral  support. 

Ralph  D.  Puckett 


ii 


Aeeasslon  For  ^ 

RTIS  GRAAI  IF 

OTIC  TAB  □ 

Unannounced  □ 

Justlf loatloQ _  _ 

Rv 

Dlatr 

Aval 

Ibutloo/ 

Lability  Codes 

Diet 

Avail 

Spec 

and/or 

lal 

Table  of  Contents 


Page 

Preface . ii 

List  of  Figures . iv 

Abstract . v 

I.  Introduction . 1 

II.  Review  of  the  Literature . 6 

III.  Network  Theory . 13 

Networks  of  M/M/1  Queues . 13 

Flow  and  Capacity  Assignment . 17 

rv.  Software  Development . 20 

Requirements . 20 

Design . 23 

Implementation . 32 

Detailed  Development . 38 

Testing . 40 

V.  Results  and  Discussion . 42 

Development  Methodology . 42 

Test  Results . 42 

Recommendations . 45 

Appendix  A;  User's  Manual . 47 

Appendix  B:  Tests . 65 

Appendix  C:  Software  Evaluation  Survey  Results . 79 

Bibliognq;>hy  . 81 


List  of  Figures 


Figure  Page 

1.  Network  Modeling . 14 

2.  Network  Parameters  (Input) . 16 

3 .  Network  Parameters  (Calculated) . 18 

4 .  Data  Structure  Design . 26 

5 .  Structure  Chart  -  High  Level  Design . 27 

6 .  Structure  Chart  -  High  Level . 35 

7 .  Structure  Chart  -  Network  Editor . 36 

8 .  Structure  Chart  -  Routuig  Editor  Module . 37 

9 .  Structure  Chart  -  Analyzer  Module . 38 

1 0.  Comparison  with  Comnet  11.5 . 44 


AFrr/GE/ENG/88D-39 


Atowt 

The  purpose  of  this  study  was  to  design  and  implement  a  simulator  to  assist  stu¬ 
dents  of  computer  networks.  The  basic  objective  was  to  create  a  software  2q)plicati(m  that 
provides  rapid  feedback  on  networic  design  decisions.  Of  particular  interest  is  the  packet 
switched  network  with  data  links  of  various  edacity  assignments.  Another  basic  objective 
was  to  create  a  graphics  interface  that  eliminated  the  need  to  learn  a  simulation  language 
while  still  maintaining  a  powerful  and  useful  product. 

The  end  product  was  a  result  of  the  application  of  both  networking  theory  as  well  as 
software  engineering  principles  with  particular  attention  being  paid  to  reliability  and 
maintainability.  With  this  tool  the  student  can  create  any  network  topology  simply  by 
pointing  and  clicking  a  mouse  and  entering  a  few  network  paranoeters  from  the  keyboard. 
The  application  can  be  run  on  a  personal  computer  -  an  environment  which  is  accessible 
and  fairly  well  understood. 

The  design  and  implenrentadon  of  the  ^plication  is  presented  in  this  work  along 
with  the  results  of  developmental  testing.  In  addition,  a  sample  of  fifteen  students  was 
chosen  to  provide  the  initial  beta  test  and  those  results  are  presented.  A  comprehensive 
user's  manual  is  included  as  an  appendix.  Finally,  several  recotrunendations  concerning 
future  develc^ment  are  discussed. 
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DESIGN  AND  IMPLEMENTATION  OF  A  PC-BASED  NETWORK 
SIMULATOR  FOR  ENGINEERING  EDUCATION 


I-  iPtypdHcnoD 


Overview 

The  Department  of  Electrical  and  Computer  Engineering  of  the  Air  Force  Institute  of 
Technology  is  involved  in  an  on-going  process  of  building  a  catalog  of  software  tools  that 
are  developed  in-house.  The  fundamental  purpose  of  each  tool  is  to  enhance  both 
educational  and  research  activities.  This  thesis  chronicles  the  development  of  one  such  tool 
aimed  specifically  at  the  design  and  analysis  of  cmnputer  communication  networks. 
Specifically,  the  tool's  purpose  is  to  automate  the  mathematics  of  computer  network  design 
in  order  to  provide  rapid  analysis  of  network  design  decisions.  The  work  drew  principally 
from  three  fields  of  study.  Two  of  these  areas  arc  computer  networks  and  software  engi¬ 
neering.  A  third  perhaps  more  subtle  and  possibly  more  intriguing  area  is  that  of  the 
human-computer  interface,  part  of  the  larger  discipline  of  what  has  come  to  be  known  as 
human  factors  engineering.  A  primary  concern  during  the  development  of  the  project  was 
that  the  software  produced  be  useful,  not  a  trivial  statement  given  die  amount  of  software 
available  that  is  difficult  to  learn  and  use.  It  became  evident  diuing  the  development  of  this 
project  that,  as  a  general  rule,  there  is  an  inverse  relationship  between  ease  of  use  and 
program  complexity.  Therefore,  much  of  the  time  and  effort  devoted  to  this  work  was 
directed  toward  the  transparency  of  the  human-machine  interface. 
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The  lemainder  of  this  chapter  will  provide  some  background  leading  up  to  a  statement 
of  the  problem.  It  will  also  describe  the  approach  taken  to  solve  the  problem  as  well  as  the 
tools  and  materials  used  in  the  development  of  the  solution.  The  following  chapter  presents 
a  review  of  the  background  literature  with  emphasis  tm  past  research  efforts  in  computer 
network  analysis  and  software  development  methods. 

Following  the  literature  review  will  be  presented  a  chapter  on  the  development  of  the 
network  theory  and  the  analytical  models  that  were  implemented.  The  succeeding  chapter 
will  provide  a  detailed  account  of  the  software  development  process  itself.  The  final  two 
chapters  will  present  results  and  discussion  and  finally  some  ideas  on  areas  in  need  of 
further  study  or  refinement 

Backpgund 

Students  in  the  computer  communication  networks  sequence  of  study  at  the  Air  Force 
Institute  of  Technology  (AFIT)  are  responsible  for  becoming  familiar  with  the  analysis  of 
many  different  types  of  computer  netwoiks.  Many  of  the  points  presented  in  lecture  are 
more  easily  understood  if  the  student  is  able  to  simulate  networks  through  the  use  of 
graphics-based  computer  aided  design  (CAD)  tools,  thus  making  the  mathematics 
transparent  There  are  presently  available  a  variety  tools  commercially  that  perform 
generalized  network  simulation  and  analysis  but  are  not  speciffcally  designed  to  enhance  the 
study  of  computer  networks.  These  applications  often  require  the  knowledge  of  difficult 
commands  or  even  an  entirely  new  computer  language,  thus  causing  the  learning  curve  of 
the  software  to  interfere  with  the  mastery  of  die  subject  material .  In  other  words,  power 
and  ease  of  use  seem  to  have  an  inverse  relationship.  Also,  these  packages  are  expensive 
and  probably  out  of  reach  of  most  personal  budgets. 
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Given  the  above  observations  it  bectxnes  apparent  that  there  exists  a  need  for  a 
software  tool  available  in  the  public  domain  targeted  at  network  topology  to  supplement  the 
material  presented  in  an  introductory  course  in  computer  networks.  The  desired  outcome 
as  defuied  by  members  of  the  faculty  at  AFTT  is  rapid  analysis  of  network  design 
decisions.  Furttermore,  the  system  developed  should  fit  into  the  somewhat  ambiguous 
genre  of  "user-firiendly"  application  software. 

Problem  Statement 

Presently  there  is  no  requirement  for  laboratory  work  to  supplement  the  lecture  in  the 
introductory  course  in  computer  networks.  In  order  to  develop  an  effective  laboratory 
program,  useful  tools  should  be  either  acquired  tn*  developed.  Presently  available  software 
tools  alone  do  not  adequately  fulfill  these  needs  and  therefore  development  of  software 
tailored  more  to  the  educational  environment  is  in  tnxler.  The  objective  of  this  research  is 
the  creation  of  a  PC-based  CAD  tool  that  automates  the  design,  analysis,  and  evaluation  of 
computer  network  topologies  presented  in  lecture. 

ApfiToach 

The  area  that  received  the  largest  amount  of  attention  was  that  of  the  user  interface.  A 
search  of  the  background  literature  revealed  some  basic  ideas  about  what  makes  a  given 
application  easy  and  interesting  to  use.  Although  the  interface  went  through  a  series  of 
refinements  the  ideas  presented  in  the  literature  continued  to  be  the  basis  for  the  design  and 
implementation.  Presently,  there  is  not  a  standard  interface  for  the  software  tools  created 
at  AFTT  and  consequently  the  visual  manifestatiem  of  the  application  developed  was  largely 
a  statement  of  the  author's  own  ideas.  Several  ideas  were  implemented  and  tested 
iteratively  until  a  final  inrplementation  was  decided  upon. 
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Another  main  concern  involved  the  search  and  acquisition  of  the  necessary  de¬ 
velopment  uwls  that  supported  graphics,  mouse  operadon,  and  printing.  Emphasis  was 
placed  on  the  level  of  support  provided,  guided  by  the  notion  that  enhanced  software 
development  tools  should  encourage  the  development  of  better  software. 

After  the  software  tools  were  selected  but  before  the  actual  development  of  the 
software  began,  some  time  was  spent  iteratively  writing  and  testing  small  routines  that 
performed  the  low  level  tasks.  For  example,  in  order  to  draw  a  computer  network  on  the 
display  several  griq)hics  primitives  were  tested.  It  became  apparent  that  some  primitives 
required  more  computational  power  (and  hence  time)  to  create  than  otl^rs,  particularly 
when  floating  point  (^rations  were  involved.  One  outcome  was  the  decision  to  use 
rectangular  rather  than  circular  objects  to  represent  the  nodes  of  a  computer  networic 

Next  it  was  necessary  to  research  the  ctxnputer  networic  theory  problem  set  to  be 
modeled  or  simulated.  This  work  relied  heavily  upon  the  textbooks  currently  used  in  the 
computer  network  sequence  of  study  at  AFTT.  The  outcome  was  a  set  of  equations  that 
were  later  mapped  into  the  software  solution. 

Given  the  set  of  software  tools  and  the  set  of  analytical  models,  the  actual  devel¬ 
opment  of  the  software  could  proceed.  The  process  required  that  the  requirements  be 
organized  and  then  mapped  into  a  preliminary  set  of  structure  charts.  From  the  structure 
charts  a  process  of  iteratively  coding  and  testing  the  software  was  undertaken.  Finally,  the 
finished  product  was  put  through  a  series  of  formal  tests  as  well  as  a  field  test  involving  the 
students  in  an  introductory  course  in  computer  networks.  Throughout  the  implementation 
phase,  advice  was  solicited  from  fellow  students  as  well  as  the  thesis  advisor  and  other 
faculty  members. 
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Materials  and  Equipment 


The  Digital  Engineering  Laboratory  at  AFTT  has  a  number  of  Z-248  miciocOTiputers 
equipped  with  mice  and  Enhanced  Graphics  Displays  (EGA).  Although  there  are  nxsre 
powerful  machines  available  in  the  lab,  the  Z-248's  were  more  plentiful  and  used  the 
popular  MS-DOS  operating  system,  already  familiar  to  a  majority  of  the  students.  Using 
these  machines  the  software  can  reach  a  larger  audience  and  the  PC  was  therefore  chosen  to 
host  the  application  developed  in  this  study.  The  actual  development  was  done  on  a  10 
MHz  8088  based  PC  compatible  machine  equipped  with  a  30-Megabyte  hard  disk,  EGA 
display,  and  Logitech  mouse. 

The  software  requires  a  PC  compatible  microcomputer  with  either  EGA  (256K)  or 
Hercules  graphics,  and  a  Microsoft  compatible  mouse.  To  produce  a  hard  copy  of  the 
drawings,  the  printer  must  support  IBM  graphics. 

The  software  was  written  in  Turbo  C,  version  1.5  customized  with  the  CXL  extended 
language  library,  version  4.0.  According  to  its  licensing  agreement,  the  CXL  package  may 
be  used  for  non-commercial  software  development  without  the  payment  of  licensing  fees. 

A  copy  of  the  package  has  been  submitted  with  the  simulator  source  code  to  the  Department 
of  Electrical  and  Computer  Engineering  in  the  School  of  Engineering  at  AFTT. 

The  Turbo  C  package  is  a  commercial  product  and  must  be  licensed  before  it  can  be 
used.  The  compiler  has  extensive  graphics  support  while  the  CXL  library  provides  mouse 
and  windowing  functions.  The  graphics  driver  (VGAEGA.BGI)  provided  with  the  C 
compiler  was  converted  to  an  object  file  and  added  to  the  graphics  library,  thus  eliminating 
the  need  for  a  separate  device  driver  to  execute  the  program. 
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II.  Review  of  the  Literature 


The  background  literature  for  this  effort  is  divided  into  two  broad  categories:  com¬ 
puter  network  analysis  and  software  design.  The  first  subset  is  concerned  with  the  object 
to  be  modeled,  that  is,  the  network  itself.  Because  the  product  of  this  thesis  will  support  a 
specific  course  sequence  at  the  Air  Force  Institute  of  Technology,  the  thesis  advisor  and 
faculty  members  have  clearly  defined  the  type  of  networking  problems  to  be  studied.  The 
second  subset,  that  of  program  design  and  implementation,  deals  with  software  engineering 
issues  and  is  well  supported  by  past  and  present  research  efforts. 

Computer  Network  Analysis 

M/M/1  Queueing  Systems.  In  order  to  simulate  the  arrival  of  traffic  into  a  network  a 
model  must  be  devised  that  reasonably  approximates  a  real  world  situation.  One  of  the 
most  widely  used  queueing  models  is  the  M/M/1  model  attributed  to  A.A.  Markov  and  de¬ 
scribed  by  Kleinrock  and  others.  This  model  is  popular  due  to  its  "memorylessness" 
property;  that  is,  the  system  is  completely  defined  by  its  present  state  and  therefore  the 
point  of  time  at  which  study  of  the  system  begins  is  irrelevant.  The  fact  that  the  analysis 
does  not  change  as  a  function  of  time  greatly  reduces  the  amount  of  analytical  complexity 
and  permits  mathematical  models  that  are  tractable.  The  continuous  M/M/1  system  is  char¬ 
acterized  by  exponential  distributions  of  both  time  between  arrivals  and  service  time  (7:94- 
98).  Tanenbaum  found  that  an  exponential  interarrival  time  density  is  a  reasonable 
approximation  to  data  packet  arrivals  in  a  networic  and  that  the  same  distribution  can  be  ap¬ 
plied  to  service  times  as  long  as  those  times  do  not  become  exceedingly  long  (11  :S8). 

jQssiSQ-  Tanenbaum  presents  an  introduction  to  the  backbone  design  of  a  data  net¬ 
work  in  his  text  Computer  Networks.  The  process  begins  by  generating  a  starting  topol¬ 
ogy  based  upon  geography  and  then  refining  the  topology  with  an  optimizing  heuristic  such 
as  die  link  deficit  algorithm.  The  link  deficit  method  assigns  links  between  stations  in  such 
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a  way  that  the  physical  lengths  of  the  links  are  nunitnized  while  also  minimizing  the  number 
of  links  connected  to  each  node.  Flows  are  then  assigned  using  the  shortest  path  algorithm 
which  requires  that  the  data  traffic  use  the  shortest  routes  available.  The  final  step  is  the 
calculation  of  the  optimal  capacity  assignntcnts  for  each  link  based  upon  the  desired  average 
delay  for  the  system.  Tanenbaum's  method  is  based  upon  static  routing  paths;  however,  as 
long  as  the  network  is  in  a  reasonable  state  of  equilibrium  the  model  should  approximate  a 
network  that  routes  its  traffic  dynamically  (1 1  ;61-71). 

Software  Development 

The  software  developn»ent  of  this  project  draws  from  the  areas  of  software  en¬ 
gineering,  database  design,  computer  graphics,  and  the  study  of  the  human-computer 
interface.  The  goal  of  this  literature  review  was  to  determine  the  present  state-of-the-art  in 
these  areas  as  they  apply  to  the  computer  environment  chosen  for  this  wodc  (the  PC- 
compatible  microconqjuter). 

Software  Engineering.  The  engineering  of  high-quality  software  can  be  broken  down 
into  four  major  subacdvides;  requirements  analysis,  design,  implementation  (coding),  and 
testing.  The  primary  purpose  of  requirements  analysis  is  to  decompose  a  complex  problem 
into  pieces  that  are  easier  to  manage.  There  are  a  number  of  different  ways  to  attack  the 
problem,  ranging  from  problem-statement  languages  to  graphical  CAD  tools.  The  desired 
result  is  a  set  of  specifications  or  diagrams  diat  describe  what  the  software  is  required  to  do 
(9:137-142). 

The  second  subactivity,  that  of  design,  is  concerned  with  dte  structure  of  the  pro¬ 
gram,  independent  of  coding  concerns.  The  design  stage  is  important  not  only  to  die 
development  of  the  software  but  also  is  critical  for  the  maintenance  of  large  software  sys¬ 
tems.  Two  methods  currendy  in  use  are  object-oriented  design  and  top-down  design.  Ob¬ 
ject-oriented  design  (OOD)  creates  a  model  of  the  real-world  problem  and  then  maps  it  into 
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the  solution  space.  It  is  a  descendent  of  data-structure  oriented  design  where  appropriate 
data  structures  are  detemined  before  any  function  generation  begins  (2:47-50).  OOD  does 
not  require  that  the  designer  map  the  real-worid  objects  into  pre-defined  structures,  rather, 
it  allows  die  creation  of  abstract  data  types.  Only  after  the  operations  on  tho%  objects  are 
defined  does  the  creation  of  implementation  details  begin  (9:357-358). 

Schildt  recommends  a  tqi-down  design  approach  based  upon  levels  of  functionality 
rather  than  levels  of  objects.  Using  this  method  the  designer  starts  with  a  general  descrip¬ 
tion  of  the  problem  and  then  works  downward,  gradually  adding  specifics.  The  first  mod¬ 
ule  designed  should  be  at  the  highest  level  of  functionality  (10:835-837). 

The  third  area  in  software  engineering  is  that  of  implementation.  One  very  popular 
method  is  incremental  testing,  made  possible  by  the  proliferation  of  interactive  terminals 
and  personal  computers.  In  incremental  testing  the  develc^ier  builds  die  software  little  by 
little,  testing  as  development  progresses.  This  method  has  a  distinct  advantage  over  that  of 
batch  submission  in  that  errors  are  caught  while  they  are  made  and  are  therefore  easier  to 
track  down,  resulting  in  a  reduction  in  the  debugging  time  required  (1 1:881 ).  Booch  ad¬ 
vocates  bottom-up  development  because  it  promotes  the  creation  of  shared  elements  or 
tools  (2:390).  When  coding,  Johnson  recommends  that  the  problems  be  first  modeled  as 
algorithms  in  order  to  avoid  the  distractions  caused  by  attention  to  details  required  when 
writing  correct  code  (6:121). 

The  final  phase  of  software  development  with  respect  to  engineering  aspects  is  that  of 
testing.  Testing  can  be  divided  into  two  types  -  black  box  and  white  box.  In  black  box 
testing  the  one  conducting  the  test  is  not  concerned  with  the  inner  woridngs  of  the  soft¬ 
ware.  Test  cases  are  sets  of  input  values  tiiat  are  expected  to  produce  certain  outputs. 
Normally,  die  test  cases  are  determined  by  die  creation  of  both  valid  and  invalid  equiva¬ 
lence  classes.  The  concept  can  be  taken  one  step  further  by  using  values  that  are  on  the 
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boundary  between  valid  and  invalid  input,  (this  method  is  smnetiiiies  referred  to  as  bound¬ 
ary  value  testingX9:48S-486). 

White  box  testing,  m  the  other  hand,  is  concerned  with  the  operation  of  the  internal 
structure  of  the  programs.  Test  data  is  chosen  such  that  all  ctmtrol  structures  within  the 
code  are  considered.  White  box  testing  tterefore  requires  that  all  paths  through  the  pro¬ 
gram  be  tested.  Obviously,  this  method  presents  logistical  problems  due  to  the  combinato¬ 
rial  explosion  of  the  number  of  paths  through  a  large  program  (S:999). 

Howden  recommends  a  functional  approach  to  program  testing.  He  suggests  that  a 
program  be  thought  of  as  a  collecdtMi  of  interacting  functions,  where  a  function  is  defined 
as  a  set  of  operadons  that  transforms  data.  This  method  requires  that  the  programmer  or 
whoever  conducts  the  test  have  knowledge  about  three  areas  related  to  the  program.  First 
of  all,  as  in  black  box  testing,  there  must  be  knowledge  of  what  outputs  values  are  expected 
fiom  a  given  set  of  inputs  (input-output).  Secondly,  there  must  be  knowledge  of  the 
proper  sequence  of  function  calls  (trace).  Finally,  it  must  be  known  which  pairs  of  events 
cause  specific  data  transformations  (interface)  (S:997). 

In  functional  testing  all  functions  in  the  program  must  be  identified  and  tested.  Fur¬ 
thermore,  all  combinations  of  statements  within  the  function  must  also  be  tested.  The 
functional  test  data  should  include  extreme  and  non-extreme  cases  tailored  to  find  faults  in 
the  constructs  that  make  up  each  function.  The  big  advantage  over  traditional  white-box 
testing  is  that  not  all  paths  in  the  program  must  be  tested  separately.  Rather,  each  functicxi 
is  tested  individually,  thus  avoiding  the  combinatorial  explosion  of  test  cases  mentioned 
earUer  (5:999). 

Database  CcMisiderations.  In  Adams'  thesis  a  study  was  made  concerning  the  type 
and  availability  of  a  data  base  management  system  (DBMS)  that  was  applicable  to  the  pub¬ 
lic  domain  and  educational  environments.  Because  much  of  his  worit  parallels  this  effort 
some  lessons  can  be  learned  concerning  which  direction  to  take.  Adams'  study  found  that 
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it  was  better  to  develop  a  simple  oiginal  design  rather  than  to  inq)lement  an  off-the-shelf 
package.  One  reason  is  that  existing  packages  are  more  powerful  than  really  needed  and 
therefore  consume  an  unnecessarily  large  amount  of  the  memory  resources  of  the  com¬ 
puter.  Another  reason  is  that  procurement  of  such  a  system  would  cause  logistical  prob¬ 
lems  due  to  copyrights  and  licensing  requirements  (l:2.2-2.4). 

Implementation  flf  Graphics.  To  guide  the  philosophy  of  the  graphics  design,  the 
work  by  Johnson  provides  a  useful  firamework  to  apply  to  the  development  of  the  graphics 
software  for  this  system.  Johnson  divides  a  graphics  oriented  program  into  three 
"worlds".  The  first  such  world  is  what  he  calls  the  "world  of  control"  which  provides  the 
means  to  alter  the  program  flow.  The  editing  and  selection  activities  are  examples  of  this 
environment  The  second  "world"  mendoi^  is  the  "world  of  reals"  or  floating  point 
representations  of  locations  and  attributes.  The  third  and  final  realm  is  the  "world  of  dis¬ 
plays"  where  all  numbers  are  of  type  signal  integer,  suggesting  that  dtere  may  exist  a  map¬ 
ping  from  the  world  of  teals  to  the  world  of  displays  but  not  vice  versa  (due  to  round-off 
errors).  Locations  and  attributes  are  presented  to  the  graphics  hardware  in  the  world  of 
displays  (6:40-41). 

Human-Computer  Interface.  The  Adams'  study  iterates  some  basic  rules  concerning 
the  develt^ment  of  the  human-ctxnputer  intoface.  These  rules  all  suggest  that  the  useful¬ 
ness  of  a  software  package  is  strongly  dependent  upon  the  user's  perception  of  the  ease  of 
its  use.  The  emphasis  must  be  placed  on  keeping  the  user  motivated.  There  are  a  number 
of  features  explained  in  the  study  that  apply  to  this  project  Such  features  are  the  use  of  the 
"mouse"  as  the  preferred  screen  manipulation  method,  the  inclusion  of  on-screen  directions 
that  supplement  the  user’s  manual,  and  such  built-in  features  as  confrimation  of  program 
termination  befrne  saving  files.  (1:3.12). 

Carrcdl  and  Mazur  conducted  a  study  ttf  Hrst  time  users  to  a  new  computing  en- 


vironmmt  They  found  diat  novice  computer  users  fear  that  improper  actions  may  some- 


how  rtamagft  the  Software  or  hardware.  Also,  most  users  new  to  a  program  or  system  will 
try  to  avoid  reading  the  documentation.  The  new  users  typically  tried  to  go  it  on  their  own 
only  to  later  become  fiustrated  and  begin  skipping  around  in  the  manuals  hoping  to  find  die 
answers  to  their  problems. 

The  study  produced  some  recommendations  concerning  the  writing  of  programs. 

First  of  all,  the  writer  should  pay  attention  to  the  level  of  expertise  of  the  user.  The  in¬ 
structions  should  be  short  and  not  too  regimented.  Also,  it  is  wise  to  avoid  the  inclusion  of 
positive  or  negative  reinforcement  messages  within  software.  If  taken  out  of  context  or  re¬ 
peated,  the  messages  can  become  annoying.  Enor  shielding  is  a  term  used  to  describe  the 
amount  of  built-in  protection  in  a  program.  "Overshielding"  occurs  when  the  software  at¬ 
tempts  to  anticipate  the  user's  improper  actions  and  then  invisibly  makes  corrections.  The 
user  bectxnes  ccmfiised  because  the  outcome  of  an  action  did  not  correspond  to  the 
(erroneous)  input  (The  machine  made  the  change  without  notifying  the  user).  The  oppo¬ 
site  end  of  the  spectrum  is  "undershielding",  where  the  user  is  allowed  to  go  ahead  and 
make  mistakes  with  no  action  being  taken.  The  programmer  should  also  avoid  error  mes¬ 
sages  that  are  too  general.  The  error  messages  should  be  comprehensive  and  all  at  the  same 
level.  Finally,  the  use  of  "cute"  phrases  should  be  avoided  because  the  novelty  of  such 
messages  soon  wears  off. 

As  far  as  terms  and  language  in  geiwral  go,  one  should  avoid  arcane  labels.  For  ex¬ 
ample,  the  substitutitm  of  "fixed  disk"  for  "hard  disk”  may  be  more  accurate  but  it  is  not  the 
commonly  accepted  term.  Labels  and  commands  should  be  simple  and  to  the  point.  Terms 
like  "save",  "close",  and  "print"  are  not  easUy  confused  and  they  adequately  describe  the 
actions  to  be  taken.  In  regard  to  the  use  of  a  mouse,  the  programmer  should  make  sure  that 
die  mouse  sensitive  areas  of  the  screen  are  large  enough  to  be  easily  selected.  One  should 
assume  diat  the  user  is  not  experienced  in  wmidng  with  a  mouse.  Finally,  good  software 
should  include  provisions  to  undo  actions  taken  in  error  (19:36-46). 
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Summary.  The  purpose  of  this  chapter  was  to  relate  this  thesis  effort  to  previous  re¬ 
search.  The  preceding  paragrty)hs  attempt  to  summarize  the  body  of  literature  invesdgated 
and  gives  some  insight  into  die  approach  taken  in  this  work.  The  intent  is  not  to  follow  a 
predeHned  path  but  to  choose  a  mix  of  the  best  methods. 


‘At- 


ni.  Network  Theory 


This  chapter  will  present  the  analytical  model  that  was  mapped  into  the  software 
solution.  It  is  important  to  note  that  a  majority  of  die  effort  was  put  into  the  design  and  im¬ 
plementation  of  the  user  interface,  while  implementation  of  the  netwoiking  algorithms  was 
relatively  straightforward.  Consequently,  other  methods  of  analysis  may  be  implemented 
without  much  difficulty  using  the  interface  developed  in  this  work.  This  subject  will  be 
discussed  further  in  the  sections  on  design  and  recommendations. 

This  chapter  does  not  attempt  to  provide  the  detailed  development  of  the  queueing  and 
network  theory  behind  the  equations  used.  The  reader  is  referred  to  Tanenbaum  (2)  and 
Kleinrock  (7)  for  more  depth  if  needed.  The  focus  of  this  chapter  is  on  what  assumptions 
have  been  made  and  how  they  affect  the  accuracy  of  the  analysis.  It  also  presents  an 
explanation  of  the  various  equations  selected  for  implementation  into  the  software  solution. 

Networks  of  M/M/1  Queues 

Network  Model.  Before  discussing  the  theory  that  drives  the  problem-solving  al¬ 
gorithms  of  the  software,  a  discussion  of  the  specific  type  of  networking  problem  is  in  or¬ 
der.  The  network  to  be  modeled  consists  of  two  basic  elements:  switching  processors  and 
transmission  lines  (2:7).  These  elements  are  manipulated  as  nodes  and  links,  respectively. 
Each  node  receives  traffic  from  two  sources;  the  incoming  links  connected  to  it  and/or  the 
host  computers  that  access  the  network  through  it.  Messages  are  made  up  of  a  series  of 
packets  of  varying  length.  Figure  1  shows  the  translation  from  the  physical  network  to  the 
abstract  noodel  for  analysis. 

The  routing  algorithm  used  is  static.  From  the  standpoint  of  an  originating  node,  all 
messages  intended  for  a  specific  destination  will  use  one  or  more  predetermined  sets  of 
connecting  links.  No  rooting  decisions  are  made  at  intermediate  iKxies  along  the  route 
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taken.  A  node  accepts  all  packets  as  they  arrive  into  its  infinite  queue.  If  the  packet  is 
destined  for  some  other  node  it  will  be  frawaided  along  the  link  specified  by  the  packet's 
routing  as  soon  as  the  link  is  free.  This  type  oi  network  is  sometimes  referred  to  as  a  store- 
and-foTward  network  (2:8). 

In  order  to  develop  a  solvable  mathematical  model,  several  simplifying  assumptions 
are  necessary.  First  of  all,  the  number  of  arrivals  during  any  interval  of  time  is  an 
independent  random  variable  (4:50).  The  steady-state  arrival  of  packets  therefore  consti¬ 
tutes  a  Poisson  process  and  is  described  by  exponential  interarrival  intervals.  This  as¬ 
sumption  appears  to  be  fairly  accurate  for  large  numbers  of  independent  customers.  As  far 
as  the  processing  of  the  packets  by  the  node,  the  exponential  service  time  assumption  also 
holds  as  long  as  service  times  arc  not  too  long.  Stated  another  way,  the  distribution  of  bits 
per  packet  is  also  a  Poisson  process  (2:58).  llrerefore,  given  exponential  interarrival  inter¬ 
vals  and  service  times  and  the  added  conditicm  that  each  link  can  process  only  one  packet  at 
a  time,  the  M/M/1  queue  serves  as  an  adequate  noodeL  Propagation  delay,  check  sum  cal¬ 
culations,  errors,  retransmissions,  and  control  overhead  are  all  disregarded. 

The  next  problem  is  how  to  treat  the  intoconnection  of  the  multiple  Markovian 
servos  that  make  up  the  communications  network.  Given  that  message  service  (or  packet 
length)  is  a  Poisson  process  each  link  can  be  considered  as  just  another  stream  of  arrivals  to 
the  node  -  a  parallel  combination  of  arrivals  to  an  M/M/1  queue.  Burke  discovered  that 
multiple  Pdsson  arrivals  can  be  added  together  and  then  treated  as  a  single  large  Poisson 
process  with  its  mean  arrival  rate  equal  to  the  sum  of  the  rates  of  the  arrival  streams  feeding 
it.  The  weakness  with  applying  this  idea  to  the  model  is  that  there  is  an  assumption  that 
packets  are  discarded  and  then  regenerated  at  each  node,  with  new  packet  lengths  being  as¬ 
signed  accmding  to  an  exponential  distribution.  This  approximation  is  known  as  the  Inde¬ 
pendence  Assumption  and  has  been  shown  by  Kleinrock  to  be  reasonably  accurate  (2:63). 
In  reality  each  packet  usually  remains  constant  in  length  from  its  pdnt  of  origin  to  its 
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destination.  There  are  exceptions.  For  example,  gateway  processors  connecting  networks 
may  modify  the  size  of  the  packets  in  order  to  accommodate  the  different  standards  of  the 
interconnected  networks. 

Network  Parameters.  Having  described  the  type  of  network  to  be  modeled,  the  next 
step  is  to  determine  the  parameters  of  interest  and  develop  the  equations  necessary  to  pro¬ 
vide  the  analysis.  The  input  variables  are  shown  in  Figure  2.  From  the  standpoint  of  a 


input  variables. 

:  traffic  for  route  i  (packets/sec) 

:  average  packet  size  (bits/pkt)  for  network 

C , :  link  capacity  in  kbps  (kilobits  per  second) 

jiC  :  service  rate  (packets/sec) 

X ,  :  average  arrival  rate  (packets/sec)  for  link  i 
(Sum  of  all  traffic  y  using  the  link) 

d  :  cost  per  kbps  (Normalized  to  1 ). 

FIGURE  2  :  Network  Parameters  (Input) 

user  on  the  network,  one  parameter  of  obvious  interest  is  how  long  does  it  take  to  route  a 
message  through  the  network.  The  answer  requires  a  calculation  of  the  mean  queueing  de¬ 
lay.  To  calculate  (telay  the  average  arrival  rate  of  the  packets  must  be  known  as  well  as  the 
average  packet  length.  Also  the  traffic  between  each  pair  of  nodes  is  needed  since  each 
route  places  additional  load  on  the  links  that  it  uses.  The  network  must  be  in  a  steady-state. 
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that  is.  the  number  of  packet  arrivals  to  each  link  must  be  less  than  the  average  rate  of  ser¬ 
vice  at  the  link.  The  number  of  atrivals  includes  all  traffic  that  uses  the  link  as  determined 
by  the  routing  table.  The  ratio  of  packet  arrivals  to  rate  of  service  is  another  parameter  of 
interest  known  as  traffic  intensity  and  gives  an  indication  of  the  amount  of  operating  head- 
room  of  a  particular  link.  These  parameters  are  summarized  in  Figure  3.  By  determining 
the  amount  of  delay  and  traffic  intensity  at  each  link,  the  behavior  of  the  network  can  be 
visualized.  The  results  of  the  calculations  can  be  tabulated  and  then  comparisons  can  be 
made. 

There  is  an  important  parameter  of  interest  that  relates  to  the  operation  of  the  network 
as  a  whole,  and  that  measurement  is  the  average  delay  for  a  packet  entering  the  network. 
Although  this  measurement  is  only  an  approximation  it  is  nevertheless  a  way  to  monitor 
general  system  performance.  The  next  section  will  discuss  how  the  average  packet  delay 
for  the  network  can  serve  as  a  constraint  for  controlling  network  costs  through  flow  and 
capacity  assignments. 

Figure  3  shows  the  formulas  for  average  link  delay,  traffic  intensity  for  a  link,  and 
the  mean  packet  delay  for  the  network.  The  reader  is  referred  to  Tanenbaum  for  a  detailed 
development  (2:62-65). 

Flow  and  Capacity  Assignment 

Flow  assignment  is  largely  determined  by  some  type  of  heuristic  process  and  will  not 
be  mentioned  in  detail  here.  What  is  irrqrortant  is  that  some  type  of  touting  algorithm  (only 
static  is  considered)  is  needed  to  assign  traffic  in  the  first  iteration  of  the  network  design. 
One  example  of  such  a  heuristic  is  the  shortest  path  algorithm.  In  this  method  routing 
between  any  two  nodes  is  determined  by  a  combination  of  shortest  geographical  distance 
and  die  amount  of  trafnc  already  assigned  to  the  links  on  the  net  After  all  routing  has  been 
accounted  for,  die  design  has  a  begirming  topology  to  which  the  analysis  can  be  applied. 
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Calculated  parameters; 

T  =  - ^ -  :  average  delay  for  link  1 

'  hc,-x, 

m 

Y=  ^Y,  :  sum  of  all  traffic  on  the  net 

I- 1 


m 

X=  .  sum  of  ail  link  arrival  rates 

1- 1 


traffic  intensity  for  link  i 


T  = 


k 

Y 


mean  packet  delay  for  network 


C 


1 

yt 


m 


optimal  capacity 
for  link  i  based  on 
delay  constraint  T 


FIGURE  3:  Network  Parameters  (Calculated) 


Using  an  iterative  process  of  routing  assignment  and  network  analysis  the  design  can  be 
optimized.  After  a  proposed  topology  has  been  determined  by  whatever  means,  die  next 
step  is  to  calculate  the  parameters  moitioned  in  the  preceding  paragraphs.  The  results  will 
probably  show  that  some  links  on  the  network  are  mcne  heavily  used  than  others  which 
suggests  tiiat  tiwre  is  inefftciency  in  the  design.  A  heavily  loaded  link  will  introduce  a  large 
delay  component  while  a  lightly  loaded  link  may  be  wa.sting  resources.  The  last  equation 
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listed  in  Figure  3  provides  a  means  to  more  efficiendy  assign  capacities  to  the  links,  subject 
to  an  average  packet  delay  that  is  acceptable.  The  equation  assumes  dtat  there  is  a  linear 
relation  between  cost  and  kbps  capacity.  The  results  are  assuming  continuous  capacities 
and  should  be  adapted  to  the  reality  of  discrete  capacity  assignments.  The  reader  is  referred 
to  Kleinrock  for  the  detailed  development  of  the  minimization  technique  used  (2:73). 

Summary 

The  material  presented  in  this  chapter  as  an  overview  rather  than  to  attempt  the  pro¬ 
vide  all  of  the  detail  necessary  to  develop  the  network  queueing  models.  The  goal  was  to 
present  the  set  of  equations  that  were  translated  into  the  number  crunching  portion  of  the 
software.  In  Figure  3  these  equations  are  summarized  and  will  be  referred  to  in  the  soft¬ 
ware  development  discussion  which  follows. 
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rv.  Software  Development 

Requirements 

Requirements  were  determined  largely  by  the  thesis  advisor  and  other  members  of  the 
faculty  who  regularly  instruct  students  in  the  computer  netwoiic  sequence.  It  is  important 
to  note  that  not  all  of  the  requirements  were  determined  before  the  development  began. 
During  the  course  of  the  work  capabilities  were  discovered  and  new  ideas  were  explored  on 
almost  a  daily  basis.  Because  a  conscious  effort  was  made  to  adhere  to  software  engineer¬ 
ing  principles,  the  changes  in  requirements  were  implemented  without  major  disruptions. 

General  Reouirements.  One  of  the  main  requirements  was  that  the  software  be 
compatible  with  computers  in  the  Digital  Engineering  Laboratory.  The  Z-248  micro¬ 
computer  with  Enhanced  Graphics  Adapter  (EGA)  display  and  Microsoft  compatible  rriouse 
was  the  targeted  environment.  These  machines  fall  into  the  general  category  of  IBM  com- 
p^bility  which  has  a  large  installed  user  base.  Because  the  software  developed  is  part  of 
the  public  domain,  it  can  be  copied  freely  and  run  on  any  machine  having  the  same 
capabilities. 

Program  flow  was  determined  to  be  as  follows:  the  user  first  must  create  a  visual 
interpretation  of  the  network  to  be  monitored.  In  most  simulation  applications,  this  actvity 
requires  a  two-step  approach  where  the  user  must  create  an  abstract  model  independent  of 
I  the  software  and  then  translate  this  visual  nxxiel  into  a  set  of  statements  that  describe  the 

system.  In  this  project,  however,  the  requirement  was  that  the  development  of  both  the 
visual  representation  and  the  description  of  the  network  be  a  one-step  process. 

The  drawing  produced  must  show  both  the  switching  processors  on  the  net  as  well  as 

f 

the  interconnecting  links.  Each  of  the  links  must  be  assigned  a  data  rate  capacity  in  kilobits 
pCT  second  (kbps).  After  the  network  is  created  and  edited  to  match  the  problem,  there 
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must  be  a  means  to  provide  the  input  of  messages  into  the  network  and  subsequently  route 
the  messages  to  predetermined  destinations.  The  routing  is  static,  that  is,  all  routing  for 
packets  arriving  at  each  node  is  determined  befcxe  it  enters  the  net.  The  alternative  is  dy¬ 
namic  routing  where  each  node  must  mate  decisions  as  to  which  link  to  route  each  packet 
as  that  packet  is  received.  In  order  to  provide  additional  flexibility  in  the  aiudysis,  the  traf¬ 
fic  arriving  at  each  node  must  be  in  packets  per  second  with  the  packet  length  being  a  vari¬ 
able  quantity  in  units  of  bits  per  packet  The  end  result  of  the  graphics  portion  of  the  soft¬ 
ware  must  be  a  visual  representation  of  tte  network  with  assigned  link  capacities  and  a 
routing  table  indicating  traffic  throughout  the  net 

Concerning  the  network  analyzer  segment  of  the  software  there  are  several  parameters 
developed  in  the  network  theory  portion  of  this  work  that  provide  performance  measures 
and  are  the  objectives  of  the  simulation.  The  parameters  desired  for  each  link  are  average 
delay,  traffic,  traffic  intensity  (ratio  of  traffic  to  capacity),  and  optimal  capacity  assignment 
based  on  an  average  delay  constraint  In  addition,  average  packet  delay  for  the  entire  net¬ 
work  is  needed.  These  parameters  were  discussed  at  some  length  in  the  preceding  chapter. 

User  Interface.  The  hunum-computer  interface  is  difficult  to  evaluate  and  altrx)st  im¬ 
possible  to  quantify.  Nevertheless,  there  were  some  general  requirements  concerning  the 
link  between  the  user  and  the  analytical  engine  of  the  software.  Most  importantly,  a  short 
learning  curve  and  ease  of  use  were  the  dominating  factors  in  the  design  of  the  user  inter¬ 
face.  More  specifically,  the  network  components  must  be  displayed  rather  than  described 
by  some  obscure  simulation  language. 

The  use  of  a  mouse  to  operate  the  application  was  determined  firxn  the  onset  to  be 
more  desirable  than  the  keyboard  for  creating  graphic  images;  however,  some  actitms  such 
as  data  and  text  input  are  only  implemented  in  a  reasonable  manner  by  using  the  keyboard. 
The  decision  was  made  that  the  mouse  be  the  primary  input  device  with  use  of  the  keyboard 
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restricted  to  input  of  text  and  numerical  data.  As  a  general  rule,  the  keyboard  was  to  be 
used  only  when  the  mouse  could  not  perform  the  same  function. 

The  process  of  inputting  commands  should  be  as  passive  a  process  as  possible. 
Menus  and  context  sensitive  prompts  shtxild  be  used  whenever  needed  to  let  the  user  focus 
his  concentration  on  the  purpose  of  the  software  rather  its  operation.  Readily  available  on¬ 
screen  help  displays  with  concise  command  explanations  also  help  satisfy  the  user-friendly 
interface  requirement. 

The  final  "lode  and  feel"  of  the  application  was  not  defined  as  a  requirement  but 
rather  evolved  during  the  design  and  implementation  stages.  The  goal  was  to  make  an  ap¬ 
plication  that  was  visually  interesting  to  use.  More  about  this  will  be  mentioned  in  the  dis¬ 
cussion  on  the  implementation  details. 

Other  General  Requirements.  There  were  other  requirements  concerning  the  op¬ 
eration  of  the  application.  It  is  desirable  to  have  the  capability  to  save  the  drawings,  routing 
tables,  and  analytical  results  to  disk  for  later  retrieval.  The  database  itself  must  be  of  a  dy¬ 
namic  nature,  that  is,  the  memory  and  disk  requirements  should  be  determiired  by  the  size 
of  the  data  (static  arrays  are  to  be  avoided).  This  requirement  allows  network  files  to  be 
limited  only  by  the  amount  of  memory  available. 

Finally,  the  design  of  the  software  must  be  easily  upgradable;  it  must  be  constructed 
such  that  future  improvenoents  are  facilitated  by  the  structure  of  the  program.  For  that  rea¬ 
son,  particular  attention  was  given  to  adherence  to  accepted  software  engineering  practices. 
This  requirement  infers  that  sometimes  trade-offs  are  made  between  speed  and  modularity. 
Function  or  procedure  calls  reduce  execution  speed  due  to  the  overhead  of  transferring 
control  to  another  segment  of  code  (saving  registers,  status,  program  counter  addresses, 
etc.)  but  make  die  source  code  more  readable  than  long  stretches  of  (faster)  in-line  code.  A 
genoal  rule  was  adopted  that  if  a  single  function  exceeded  one  page  of  code,  it  was  proba¬ 
bly  too  long  and  should  be  divided  into  smallo'  fiincticms. 
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It  was  expected  that  throughout  the  development  of  die  software,  changes  would  be 
requested  by  prospective  users.  Modularity  of  the  design  as  well  as  other  weU  accepted 
software  en^neering  practices  gready  enhanced  the  modifiability  of  the  code.  During  the 
coding  phase  several  suggestions  were  indeed  made  by  faculty  members  and  colleagues  in 
the  lab.  These  suggestions  were,  for  the  most  part,  inqilemented  without  greatly  affecting 
the  rest  of  the  code. 

Summary.  The  set  of  requirements  as  outlined  defines  what  the  application  is  to  ac¬ 
complish.  The  overriding  objective  was  to  develop  a  tool  diat  could  be  quickly  learned, 
was  interesting  to  use,  and  performed  the  job  for  which  it  was  intended. 

Design 

The  design  process  was  divided  into  three  major  categories.  They  were  1)  the  cre¬ 
ation  of  the  objects  and  their  operations,  2)  how  the  data  was  structured  and  3)  program 
structure. 

Operations  sm  dl£  Network  Objects.  Before  developing  the  database  it  was  first  nec¬ 
essary  to  determine  the  objects  and  their  op^ations.  In  a  vector  graphics  design  approach 
such  as  the  one  used  in  this  project,  images  are  not  stored  as  collections  of  pixels  (picture 
elements).  Rather,  each  object  is  given  a  set  of  attributes  that  is  accessed  each  time  the  ob¬ 
ject  is  redrawn.  Each  collection  of  attributes  can  be  thought  of  as  a  set  of  directions  for  a 
set  of  tools.  For  example,  in  this  woik  oto  of  the  objects  is  the  networic  node,  and  each 
node  must  have  a  set  of  attributes  that  uniquely  describes  it  Each  node  is  defined  sin:q)Iy 
by  its  position  on  the  x-y  plane  of  the  screen  grid  along  with  a  single  character  identifier. 
Given  the  above  information  die  node  can  be  reconstructed  using  some  type  of  routine  that 
can  draw  and  fill  a  gn^hic  primitive  and  then  label  it  All  else  that  is  needed  is  a  reference 
or  pointer  to  its  position  in  memory  so  that  the  program  can  access  it 
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There  were  three  major  objects  created.  As  just  menticmed,  one  of  die  objects  was 
detennined  to  be  the  networic  node,  which  corresponded  to  the  message  switcher  of  the 
physical  networiL  The  other  objects  are  the  data  link  (transmission  channel)  and  the  route 
(static  routing  desciiptitMi).  The  link  is  the  basis  for  the  analytically  intensive  operations  of 
the  implication  and  is  described  graphically  by  its  starting  and  ending  points  on  the  screen 
grid.  Its  other  attributes  are  the  parameters  as  mentioned  in  the  chapter  on  network  theory  - 
link  capacity,  traffic  load,  traffic  intensity,  average  delay,  and  optimal  capacity  assignment 
The  calculations  of  these  parameters  are  additional  operations  on  the  link  object  The  third 
major  object  is  the  route,  which  is  composed  of  an  ordered  set  of  nodes  and  a  measure  of 
the  traffic  routed  between  the  endpoints. 

When  discussing  the  vectored  ajmroach  to  the  graphics  design  the  question  arises  as 
to  what  type  of  drawing  tools  are  needed.  The  software  development  therefore  temporarily 
departed  from  the  usual  sequence  of  completing  the  design  before  considering  implemen¬ 
tation  details  and  focused  on  developing  a  set  of  tools  to  perform  the  low-level  graphics.  In 
order  to  establish  the  graphics  potential  of  the  application  some  time  was  spent  in  the  early 
stages  researching  methods  of  producing  primitives  (circles,  lines,  rectangles,  etc.).  AFTT 
has  developed  in-house  a  set  of  routines  that  perform  these  tasks.  These  routines  were 
written  to  be  compiled  with  either  Microsoft  C  or  C86.  The  other  environment  considered 
was  the  Turbo  C  compiler.  Version  1.S,  which  at  the  time  had  only  recently  been  released. 
The  Turbo  C  environment  offered  a  rich  set  of  graphics  routines  that  also  provided  all  of 
the  functions  needed.  Due  to  the  author's  familiaity  with  the  package  along  with  other 
factors  the  Turbo  C  system  was  selected,  aldiough  either  environment  could  have  been 
used.  There  was  also  no  specific  requirement  diat  the  software  be  written  in  the  C 
language,  but  one  of  the  personal  objectives  of  the  fmoject  was  for  the  researcher  to  become 
more  proficient  in  C  programming.  There  are  other  development  environments  for  die  PC 
microcomputer  that  provide  at  least  the  same  level  of  graphics  support 
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Database.  A  linked  list  was  selected  to  represent  the  objects  in  ntemory.  This  data 
structure  supports  the  creation  of  arrays  of  variable  sizes.  Menxvy  is  allocated  as  each  ele¬ 
ment  is  added  to  the  database  and  freed  each  time  an  element  is  delved  ((fyiuunic  al- 
locadtm).  It  also  allows  data  to  be  inserted  in  ordn’  and  deleted  without  manipulation  of  the 
entire  file.  As  elements  of  die  list  are  deleted  or  created  only  a  few  pointer  updates  are 
necessary.  A  linked  list  may  be  singly  linked,  widi  a  pointer  to  die  next  element,  or  doubly 
linked,  with  pointers  to  both  the  previous  and  the  next  elements  of  die  array.  The  double- 
linked  list  was  chosen  because  it  can  be  searched  in  either  direction,  and  it  has  the  added 
security  of  being  constructed  either  forward  or  backward  using  separate  sets  of  pointers.  It 

ttimed  out  that  a  single  linked  list  would  have  worked  equally  as  well  and  would  have  also 

\ 

had  the  advantage  of  consuming  a  slightly  smaller  amount  of  memory  (2  bytes  per  element 
due  to  one  less  pointer  per  element). 

Figure  4  depicts  the  structure  of  the  data  base  used  for  the  network.  There  are  three 
data  elements  corresponding  to  the  sets  of  nodes,  links,  and  routes.  The  node  and  route 
struaures  were  relatively  simple,  having  few  elements.  Note  that  the  route  structure  has  no 
gr{q)hical  information  since  all  of  the  graphics  details  of  the  network  are  defined  in  the  links 
and  nodes.  The  link  element  contains  most  of  the  network  information  and  is  largely  a 
result  of  the  mapping  of  the  parameters  presented  in  the  chapter  on  network  theory. 

Toolevel  Design.  Hgure  5  depicts  tire  original  highlevel  design.  The  highest  level 
units  are  an  executive  module  ('Toptrrenu”)  and  three  subordinate  units  ("Drawnet", 
"Defroute",  and  "Analyze").  The  executive  module  handles  filename  selection  and  pro¬ 
vides  a  menu  to  give  the  user  the  choice  of  which  of  the  three  lower  modules  to  run.  The 
solid  lines  show  the  lines  of  control  as  well  as  the  hierarchy  of  the  design  while  the  dotted 
lines  show  tiiat  control  can  be  passed  fieely  anxxig  tire  three  main  nrodules  while 
manipulating  the  same  set  of  files.  The  tixxlules  shown  subordinate  to  the  tiiree  main 
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Figure  5.  Structure  Chart  -  High  level  design 
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I  modules  were  created  to  handle  tasks  that  were  determined  to  be  necessary  early  in  die  de- 

I  sign.  More  acdvides  were  created  during  the  implementation  phase. 

The  three  main  modules  divide  the  operation  of  the  application  into  three  functional 
j  units.  The  first  module,  Drawnet",  is  concerned  with  actually  creating  and  editing  the 

network  to  be  studied.  Like  the  top  level  executive  module  it  too  is  a  selectitxi  and  deci¬ 
sion  point  Subordinate  to  the  "Drawnet"  executive  are  several  modules  that  perform  the 
major  operations  (xi  both  the  graphical  elements  and  the  files.  The  module  names  were 
chosen  so  as  to  be  self  descriptive.  At  the  same  logical  level  as  "Drawnet"  is  the  "Defroute" 
module  and  its  purpose  is  to  create  and  edit  the  routing  matrix.  Together  "Drawnet"  and 
"Defroute"  perform  all  of  the  graphics-oriented  tasks.  The  third  module,  "Analyze",  is  the 
number  crunching  part  of  the  application.  It  applies  the  network  theory  formulas  to  the 
graphically  created  database. 

Lower  Level  Functions.  Subordinate  to  the  module  "Drawnet"  (Figure  S)  are  defined 
six  activities  that  divide  up  the  process  of  creating  and  editing  a  network  drawing.  First  of 
all,  the  disk  files  that  contain  the  data  must  be  either  created  or  opened  if  already  available. 
The  "Loaddwg"  module  performs  both  functions  by  accepting  a  filename  and  then  loading 
the  file  from  disk  or,  if  not  already  existing,  by  creating  a  new  file.  The  file  is  transferred 

I 

I  to  memory  by  successively  allocating  storage  fcx*  each  data  structure  and  then  transferring 

I  the  dau  from  disk.  The  process  continues  until  the  EOF  marker  is  read.  It  provides  two 

types  of  error  handling.  The  firet  "error"  is  when  the  file  is  not  found  in  which  case  it  sim- 
I  ply  creates  the  file  as  mentioned  earlier.  The  second  error  condition  is  when  there  is  in¬ 

sufficient  memory  available  to  load  the  data,  in  which  case  an  out-of-menx>ry  error  is  dis- 
I  played  and  control  is  returned  to  the  calling  module. 

j  The  "Savedwg"  nxidule  reverses  the  "Loaddwg"  process  by  transferring  the  data 

^  from  memory  to  disk.  In  order  to  transfer  the  data  it  must  first  open  the  disk  file.  Iffor 
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I  some  reason  the  disk  file  cannot  be  found,  an  error  is  displayed.  All  data  in  memory  re- 

mains  available  to  the  application  after  the  save. 

The  remaining  modules  manipulate  the  elements  of  the  drawing.  First  of  all,  the 

i  "Drawnode"  module  when  selected  reads  the  mouse  position  and  waits  for  a  button  click. 

When  the  button  is  pressed,  control  transfers  ro  a  routine  that  draws  the  node  (in  whatever 
form  later  decided  upon  by  the  implementadcxi)  and  inserts  the  node  data  structure  into  the 
database  in  alphanumeric  order.  The  module  must  also  prompt  the  user  for  a  single  char¬ 
acter  label  and  then  correlate  the  label  with  the  node's  data  structure.  The  reason  for  the 
single  character  node  label  will  become  clear  when  the  routing  module  is  discussed.  When 
creating  the  structure  of  the  node,  pointers  to  the  previous  as  well  as  the  next  element  in  the 
database  are  added. 

The  other  major  drawing  element  is  the  link  and  is  also  created  using  mouse  input 
The  link  module  cormects  existing  nodes  and  prompts  the  user  for  the  capacity  of  the 
transmission  line  it  represents.  In  its  original  form  the  module  fonned  cmly  full  duplex 
links,  but  this  task  was  modified  later  on  during  the  implementation  to  include  simplex 
links.  At  this  point  each  link  consists  of  only  the  endpoints,  the  position  on  the  screen,  and 
its  capacity  in  kbps  along  with  pointers  to  the  previous  and  next  elements  in  the  link  array. 
After  the  link  is  created,  its  structure  is  inserted  in  alphnumeric  order  in  the  link  data  array. 

Any  useful  drawing  editor  must  provide  the  capability  to  erase  objects.  This  design 
provides  a  "Delete"  module  which  serves  as  the  executive  for  the  modules  that  oase  the 
nodes  and  links.  Mtxe  will  be  mentioned  about  the  erase  functions  in  the  section  on 
implementation. 

The  fmal  submodule  in  the  design  of  the  drawing  editor  is  the  "Printdwg"  module  and 
provides  the  ability  to  make  printed  copies  of  a  network  drawing  for  later  reference. 

The  second  major  module  discussed  is  "Defroute",  or  the  routing  editor.  It  controls 
five  sulwaodules  (Figure  5).  First  of  all,  the  route  data  structure  is  similar  in  omstruction 
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to  the  link  and  node  data  structures  and  the  same  file  operation  routines  can  therefore  be 
adapted  to  routes.  These  activities  are  covered  by  the  "Loadroute"  and  "Saveroute" 
submodules.  Also,  as  in  the  drawing  editor,  there  must  be  a  method  of  creating  the  routing 
able  and  if  the  requirement  of  using  die  mouse  as  the  primary  input  device  is  followed,  a 
route  should  be  created  by  pointing  and  clicking  on  each  node  along  the  desired  route.  This 
ability  is  provided  for  in  the  "Cieateroute”  module.  It  also  creates  a  character  string  made 
up  of  the  labels  of  the  nodes  that  it  contains.  This  string  is  represented  in  die  data  structure 
by  the  "path"  element  (Figure  4).  The  module  must  also  allow  entry  of  route  traffic,  either 
in  the  forward  direction  or  in  both  diiecti(»is.  One  distinction  between  "Detioute"  and  the 
drawing  editor  is  that  here  one  is  working  with  two  things,  the  network  drawing  and  the 
routing  table,  rather  than  the  network  alone.  Consequendy  there  must  be  a  means  of 
viewing  the  routing  table  either  by  displaying  both  the  network  and  routing  simultaneously 
or,  better  yet,  by  providing  a  second  display  that  is  called  up  smoothly  and  quickly  in  order 
not  to  disrupt  the  route  creation  process.  The  "Viewroute"  module  is  resorved  for  this  ac¬ 
tivity.  Finally,  as  with  the  drawing  editor,  there  is  a  module  that  deletes  entries  from  the 
database  ("Delroute"). 

There  is  one  primary  module  remaining  to  be  discussed  -  the  "Analyze"  module 
where,  as  mentioned  earlier,  the  mathematical  equations  are  implemented.  "Analyze"  ac¬ 
complishes  this  by  iteratively  calculating  the  network  parameters  whenever  variables  are 
changed.  In  Figure  5  the  reader  will  see  that  this  module  cmitrols  several  subordinate 
fiincticms.  As  in  the  other  primary  modules,  there  is  a  unit  to  transfer  the  data  finom  disk  to 
memory  as  well  as  another  module  to  save  the  data  to  disk  ("Loaddata"  and  "Savetable"). 
The  remaining  units  have  no  analog  in  the  other  two  primary  nxxlules  and  each  unit  will  be 
discussed  individually. 

Before  die  analysis  of  the  network  can  take  place  there  must  be  a  provision  for  entN- 
ing  the  average  size  of  the  packets  in  the  net  "Getpktsize"  provides  this  ability  as  well  as 
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the  option  to  modify  the  packet  size  later  if  desired.  This  module  is  automatically  called 
when  the  Analyzer  is  invoked  and  no  packet  size  has  yet  been  entered. 

Because  diere  are  several  submodules  with  separate  sets  of  instmctions  for  the  user  to 
control  it  seems  that  some  type  of  on-screen  help  is  apprq[>riate  here.  The  "Analysishelp" 
module  is  intended  to  provide  an  on-call  list  of  directions  that  correspond  to  all  of  the  activ¬ 
ities  in  the  "Analysis"  module.  By  using  an  cm-call  help  function,  the  commands  displayed 
on  the  main  module  are  kept  to  a  minimum  of  characters,  thus  freeing  up  the  screen  for  the 
analysis  results. 

Again  referring  to  Figure  S,  the  "Changecap"  module  allows  the  user  to  modify  the 
capacity  assignment  of  any  link  in  the  database.  Using  the  formula  given  in  Figure  3  for 
optimal  capacity  assignment,  the  "Opt.O^acity”  nxidule  calculates  the  optimal  capacity  for 
all  of  the  links  upon  input  of  an  average  network  delay  constraint.  The  calculated  optimal 
cj^acides  arc  then  entered  into  the  link  database.  Carrying  this  line  of  calculation  one  step 
further,  the  "Replacecj^"  module  provides  the  user  with  the  capability  of  replacing  all  of 
the  capacity  assignments  for  the  links  with  the  q>timal  capacity  assignments  as  calculated  in 
the  "C)pt_Capacity"  module.  The  average  netwoilc  delay  can  be  viewed  at  any  time  by 
invoking  the  "Showdelay"  activity. 

The  one  remaining  module  yet  to  be  di«;ussed  is  "Altroute"  and  will  be  treated  dif¬ 
ferently.  The  intention  of  this  module  was  to  provide  a  path  to  an  expert  system  that  lodes 
at  the  present  state  of  the  network  and  by  using  some  type  of  intelligent  algorithm,  makes 
suggestions  for  alternate  routing.  This  module  was  given  a  separate  compilation  unit 
during  the  coding  of  the  application. 
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Implementation 

Environment  As  mentioned  eailier  in  this  chapter,  the  Tuitx)  C  development  system 
was  selected  to  implement  the  design.  For  die  purposes  of  this  project  the  Tuitx)  C  version 
1.5  compiler  provided  most  of  the  cs4>abilities  needed  with  the  major  exception  of  the 
mouse  drivers.  The  Z-248's  in  the  Digital  Engineering  Laboratory  ere  equipped  with  Log¬ 
itech  Mice  which  are  Microsoft  Mouse  conq>atible.  In  order  to  satisfy  the  requirement  that 
the  application  be  mouse  driven  a  search  was  conducted  in  order  to  find  the  driver  support 
needed.  AFTT  has  developed  in-house  a  set  of  mouse  drivers  written  in  C  and  assembly 
code.  These  drivers  were  originally  written  for  the  Mouse  Systems  Mouse  and  were  there¬ 
fore  not  selected. 

Fortunately,  there  are  several  libraries  of  C  functions  available  from  bulletin  board 
systems  (BBS)  and  the  national  on-line  computer  services.  Several  libraries  were  evaluated 
before  deciding  upon  the  CXL  Extended  Library  version  4.0.  The  CXL  library  seems  to 
fill  in  many  of  the  gaps  in  the  Turbo  C  library.  Most  notably,  it  provides  extensive  mouse 
and  windowing  support.  Turbo  C  1.5  supports  windowing  but  at  a  much  lower  level  and 
is  therefore  more  difficult  to  implement  than  the  CXL  functions.  The  (ZXL  licensing 
agreement  allows  use  of  the  code  without  paying  a  fee  as  long  as  the  work  is  for  non-com¬ 
mercial  purposes.  A  copy  of  the  library  has  been  submitted  along  with  the  source  code  for 
the  simulator. 

The  environment  used  for  this  thesis  effcxt  was  a  somewhat  customized  version  of 
the  off-the-shelf  package.  First  of  all,  the  BGI  graphics  driver  file  "EGAVGA.BG!"  is 
usually  required  at  run-time  for  aU  EGA  or  VGA  graphics  routines  written  in  Turbo  C.  For 
this  project,  the  drivo*  was  integrated  directly  into  the  gnqrhics  library  of  the  C  compiler  by 
first  cmivetting  it  to  a  ".obj"  file  using  the  special  application  BGIOBJ£XE  that  comes 
standard  with  the  Turbo  C  package.  Then  the  TUB  JEXE  application  was  used  to  add  the 
new  (Aject  file  to  the  Turbo  C  graphics  library  file.  If  this  conversion  is  attenqrted,  the 


32 


programmer  must  make  provisions  for  having  the  device  driver  integrated  directly  into  the 
graphics  library  by  modifying  the  source  code  that  initializes  the  graphics  system.  The 
purpose  for  integrating  the  graphics  driver  was  to  simply  eliminate  the  extra  file  needed  at 
run  time. 

Both  the  graphics  and  CXL  library  files  were  integrated  into  the  main  library  file 
(CS.LIB)  of  the  Turbo  C  package.  The  CS.LIB  library  file  contains  most  of  the  general  C 
routines  and  supports  the  "small”  memory  model.  The  small  memory  nnodel,  which  limits 
the  code  segment  and  data  segment  of  the  code  to  64K  each,  seemed  to  work  well.  It  sup¬ 
posedly  produces  faster  executable  code  by  making  all  jumps  intrasegment. 

Some  mention  should  be  made  of  display  modes  on  the  PC.  The  EGA  card  operates 
in  two  modes  -  text  mode  and  graphics  mode.  In  text  mode  all  screen  writes  use  the  built- 
in  character  generating  routines  of  the  ROM  BIOS.  Resolution  is  80  characters  wide  by  25 
characters  high.  The  toplevel  and  analyze  modules  were  written  using  this  mode.  The 
graphics  mode  is  a  direct  pixel  manipulation  of  the  screen  and  allows  more  flexibility  and 
resolution.  Resolution  is  640  pixels  wide  by  350  pixels  high.  Modes  can  be  mixed  to  a 
limited  extent.  The  drawing  and  routing  editors  both  work  predominantly  in  the  graphics 
mode  with  a  top  line  of  text  mode  characters  added  for  instructional  purposes.  On  ma¬ 
chines  that  do  not  support  separate  floating  point  operations  (using  the  80x87  chip)  the 
drawing  of  arcs  is  a  computationally  expensive  operation.  Thus  the  decision  to  avoid 
drawing  circles  and  arcs  was  made  early  on.  An  exception  was  matte  when  the  use  of  ar¬ 
rows  to  indicate  traffic  direction  was  implemened  Each  arrow  was  compxrsed  of  either 
one  or  two  filled  arcs,  depending  on  its  orientation. 

Appnoximately  2(X)0-i-  lines  of  code  were  developed  in  this  work  and  with  the  addi¬ 
tional  3(XXH  lires  of  header  code  the  total  came  to  over  50(X).  Advantage  was  taken  of  Cs 
ability  to  suppxrrt  seprarate  compilation  units  by  dividing  the  source  code  into  three  seprarate 
files.  One  file  suprported  all  of  the  graphics  and  implenented  the  "Drawiwt"  and  "Defioute" 
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modules  (See  Figure  5).  The  second  file  implemented  the  "Analyze"  module  while  the 
smaller  "Altroute"  module  was  separately  compiled  in  order  to  facilitate  future  develop¬ 
ment. 

Methods.  In  the  coding  process  a  technique  of  iterative  coding  and  testing  was  used. 
Beginning  with  the  low  level  graphics  functions,  dummy  executive  programs  were  written 
to  control  logical  grouping  of  functiwis.  Small  sections  of  code  corresponding  to  the  mod¬ 
ules  in  the  structure  charts  as  shown  in  Figures  6  through  9  were  written  and  tested  for 
functionality.  These  structure  charts  were  developed  from  the  original  chart  shown  in  Fig¬ 
ure  5,  and  resulted  from  the  finalization  of  the  design  during  the  implementation  process, 
thus  providing  a  de  facto  test  of  the  maintainability  of  the  software  while  still  under  devel¬ 
opment.  Because  of  the  experimental  nature  of  this  project,  following  a  rigorous  design 
process  in  great  detail  before  beginning  the  implementation  was  not  possible.  In  the  au¬ 
thor's  opinion,  if  development  had  strictly  adhered  to  the  classical  sequence  of  requirement 
definition  before  design  and  design  before  implementation,  the  resulting  software  would 
have  been  more  limited  in  its  capabilities. 

Due  to  the  hardware  intensive  nature  of  this  application,  many  of  the  functions  do  not 
fall  within  the  proposed  ANSI  standard  for  the  C  programming  language.  The  code  did, 
however,  make  use  of  the  ANSI  recommended  practice  of  function  prototyping  in  order  to 
enforce  stronger  type  checking  than  that  provided  in  Kemigan  and  Ritchie's  original  im¬ 
plementation  of  the  language.  Function  prototyping  checks  all  parameters  that  are  passed  to 
functions.  All  of  the  passed  parameters  must  agree  with  the  original  function  declaration 
prototype. 

Global  variables  were  implemented  but  kept  to  a  minimum.  Only  those  variables  that 
were  required  access  by  a  very  large  portion  of  the  code  were  declared  as  global.  The 
database  and  filename  as  well  as  the  mouse  status  are  examples.  The  reader  is  referred  to 


34 


Figure  9.  Structure  chart  for  analyzer  module 
the  source  code  available  from  the  department  of  Electrical  and  Computer  Engineering  in 
the  School  of  Engineering  at  AFTT  for  specific  details. 

Detailed  PevelopmenL 

Figures  6  throu^  9  depict  the  final  smiaure  of  the  application.  Comparisons  are 
now  made  widi  the  original  design  of  Figure  S. 


Toplevel.  Figure  6  shows  a  modificaiion  of  the  original  design  in  terms  of  flow  of 
control  Most  notably  the  drawing  and  routing  table  loaders  are  called  firom  the  toplevel 


module  in  order  to  provide  the  flexibility  of  gmng  directly  to  any  of  the  three  major  nxxl- 
ules  (shown  in  boldface  type).  The  analyze  function  is  displayed  as  being  subordinate  to 
the  drawnet  and  defioute  functions  but  in  actuality  it  can  call  either  function  under  certain 
conditions  (As  explained  in  the  User's  Manual  included  in  the  Appendix). 

The  pneanalyze  function  is  simply  a  test  fOT  the  existence  of  an  entry  for  packet  size. 

If  a  packet  size  has  already  been  defined  program  control  transfers  directly  to  analyze. 
Otherwise  it  prompts  for  and  receives  user  input  for  the  parameter. 

Drawing  Editor.  Hgure  7  depicts  the  inqjlementadon  of  the  drawnet  nxxlule.  It  is 
left  relatively  intact  with  the  exception  of  an  additional  module.  "Quitroute"  was  added  to 
check  for  updates  in  the  touting  table  bef(»e  amtrol  is  transferred  away  firom  the  drawing 
editor.  It  decides  if  changes  have  been  made,  saves  the  edited  route  if  so  instructed  using 
"saveroute",  and  then  returns  control  to  the  "drawnet"  executive. 

The  "delete"  module  has  two  subfunctions  that  delete  either  a  node  or  link.  The 
"delinks"  function  performs  the  actual  mechanics  of  deleting  a  link  and  is  used  for  both 
"delnode"  and  "dellink".  It  is  called  by  both  to  provide  the  feature  of  having  a  node  dele¬ 
tion  automatically  invtdce  the  deletion  of  all  links  that  are  connected  to  it. 

Also  down  in  the  hierarchy  is  the  "refscm"  function.  It  is  called  by  several  higher 
level  functions  to  redisplay  the  database  after  changes  have  been  made,  redrawing  all  of  the 
network  gn^hic  components  by  cycling  through  the  link  and  node  data  structures. 

Routing  Editor.  Reference  Figure  8.  The  routing  editor  keeps  all  functions  defined 
in  the  structure  design  drawing  and  adds  more  cfetail.  "Savedwg"  is  necessary  in  ordo’  to 
check  for  updates  to  the  drawing  before  leaving  the  module.  Also,  tiie  "refscm"  and 
"saveroute"  functions  are  called  from  this  naodule  as  they  were  fmn  the  "drawnet"  module. 
The  only  new  component  is  the  "buildtable"  function  which  creates  and  updates  the  display 
of  the  routing  table  in  the  background  page  screen  menooiy  as  routes  are  added  or 
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deleted.  The  memory  resident  quality  is  useful  in  that  the  routing  table  can  be  viewed 
virtually  instantaneously  from  the  routing  editor  by  using  die  viewioute  option. 

Analyzer.  Figure  9  shows  the  final  structure  chart  for  die  third  module.  ByoMii- 
parison  with  Figure  5  one  can  see  little  modification  from  the  original  design.  The  one  ad¬ 
ditional  function  called  from  the  executive  module  is  the  "display"  function  ii«diich  writes 
the  results  to  the  screen  in  table  form.  Subordinate  to  the  "savetable"  function  is  the 
"savetotext"  module  which  creates  an  ASCII  file  copy  of  the  display. 

Subordinate  to  the  "altroute"  module  are  "critlink"  and  "longroute".  "Ciitlink" 
searches  for  the  link  that  has  the  greatest  traffic  intensity.  "Longroute"  searches  duough 
the  route  database  and  displays  all  routes  that  contain  the  link  returned  by  "critlink".  It  also 
computes  and  displays  the  sum  of  all  delays  along  each  flagged  route. 

Testing 

Black  Box  Testing.  Black  box  testing  was  performed  by  first  determining  the  equiv¬ 
alence  classes  and  then  devising  test  cases.  The  test  cases  covered  both  valid  and  invalid 
equivalence  classes  using  random  and  boundary  values  for  inputs.  Appendix  B  lists  the  set 
of  equivalence  classes  and  test  cases  used. 

Functional  Testing.  Functional  testing  was  performed  (a  subset  of  exhaustive  white 
box  testing)  during  the  iterative  coding  and  testing  process  of  irrqrlementation.  New  tests 
were  performed  with  each  addition  of  a  logically  coherent  section  of  code. 

Comparisons  ]q  Other  Simulations.  The  example  from  the  Tanenbaum  text  was 
modeled  using  both  this  simulator  and  COMNET  D.S  from  CAQ  (8).  COMNET  is  a 
telecommunications  network  simulator  that  uses  adaptive  routing  rather  than  static  routing. 
It  also  does  rx>t  assume  independent  links  for  end-to-end  performance  measures.  Its  results 
always  include  startup  and  steady-state  values  rather  than  steady-state  only  as  in  this 
project 
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Field  Testing  and  Evaluation.  Members  of  an  introductay  class  in  computer  net- 
worts  tested  and  evaluated  die  software  as  applied  to  a  networking  problem.  The  software 
was  judged  mainly  cm  the  quality  of  the  user  interface  and  its  effectiveness  as  a  learning 
tool.  Participants  were  asked  to  complete  an  evaluation  form  and  make  general  comments. 

Other  Tests.  The  capability  to  handle  large  networking  problems  was  tested  by  cre¬ 
ating  a  network  with  60  nodes  and  106  links  and  then  observing  how  the  program  handled 
node  and  link  deletions  as  well  as  screen  refi^shes.  Also  tested  was  the  consistency  of  the 
drawing  elements  as  a  ftinctitMi  of  their  orientation  on  the  screen.  This  test  was  performed 
by  drawing  links  at  approximately  four  degree  intervals  radiating  fixrm  a  central  node  in  a 
full  360  degree  sweep.  Examples  are  included  at  the  end  of  Appendix  B. 


V.  Results  and  Discussion 


Devel* 


It  Methodology 


The  application  developed  in  this  study  was  the  result  of  a  pnxxss  of  discovering 
capabilities  and  requirements  and  then  applying  the  software  development  process  to  reach 
the  solution.  The  reason  behind  any  perceived  success  is  attributed  largely  to  modularity  of 
design  and  quality  of  the  development  environment. 

There  were  some  aspects  of  the  study  that  were  more  challenging  than  others. 
Getting  started  was  a  slow  process  due  to  the  large  selection  of  development  environments 
available.  Much  time  was  spent  writing  and  testing  small  drivers  and  routines  that  manip¬ 
ulated  the  color  graphics  and  the  mouse;  however,  once  these  low-level  issues  were  re¬ 
solved  the  networic  algorithms  were  in^lemented  without  a  great  deal  of  difficulty.  The 
Turbo  C  compiler  (the  environment  finally  decided  upon)  seems  to  produce  reasonably  fast 
executable  code  without  having  to  resort  to  assembly  language  routines.  It  is  not  known 
how  well  the  product  may  have  turned  out  if  some  other  set  of  tools  had  been  used. 

As  a  side  note,  the  entire  application  was  created  without  the  use  of  a  "goto"  state¬ 
ment;  however,  many  of  the  functitms  were  terminated  by  the  use  of  another  function  call, 
which  was  often  of  a  recursive  nature.  This  method  of  coding  provides  the  power  and 
flexibility  of  the  "goto"  statement  without  creating  the  readabili^  problems  often  associated 
with  it. 


Test  Results 

Black  Bnx  and  Functional  Tests.  In  the  opinion  of  the  author,  testing  probably 
serves  its  most  useful  purpose  when  modifications  are  done  to  an  existing  design.  As 
mentioned  earlier  nuuiy  lequirracnts  were  detmnined  and  modified  diroughout  die  devel- 
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opment  i^ase  of  the  study.  As  each  set  of  requireinent  modifications  wete  in^temented, 
subsets  of  the  suite  of  test  cases  presented  in  Appendix  B  were  run.  Most  of  the  errors 
discovered  were  not  of  the  classical  strftware  en^neering  type,  that  is  to  say,  data  and  code 
corrupdon  did  not  appear  to  any  great  extent  This  result  can  be  attributed  to  the  use  of  a 
structured  language  along  with  modularity  of  die  design. 

The  majority  of  errors  that  did  appear  had  to  do  with  graphics  issues.  For  example, 
if  a  certain  object  on  the  screen  were  changed,  another  object  created  by  some  other  func¬ 
tion  might  be  affected  by  being  overwritten  or  crowded.  These  problems  were  easily  spot¬ 
ted  due  to  the  instant  feedback  nature  of  the  CRT  display. 

Comparison  with  COMNET  II.S.  The  networking  problem  presented  in  the 
Tanenbaum  text  was  modeled  using  both  diis  simulator  and  the  COMNET  package 
(8)(1 1:63-64).  Results  of  both  methods  are  shown  in  Figure  10.  Although  the  trends  are 
similar  the  average  delay  shown  by  the  COMNET  curve  is  consistently  lower.  The  reason 
for  the  different  results  is  probably  attributed  to  the  routing  stratagies  used.  COMNET 
implements  a  routing  optimization  technique  where  the  routing  selected  in  the  example  is 
somewhat  randtxn.  Another  notable  difference  in  the  two  methods  is  COMNETs  lack  of 
use  of  the  independence  assumption.  In  other  words,  in  COMNET  a  packet  maintains  a 
constant  size  from  origin  to  destination  rather  than  being  repeatedly  regenerated  along  its 
route. 

It  should  be  noted  that  COMNET  can  be  considered  to  be  more  of  a  "true"  simulator 
in  that  it  produces  entities  and  collects  statistics.  The  software  presented  in  this  work  is 
concerned  more  with  the  q)plication  of  mathematical  nxxlels  to  various  network  designs 
originated  by  the  user  and  therefore  does  not  fall  within  a  strict  definition  of  simulation 
software. 
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Field  Test  Results.  Fifteen  students  in  an  introductory  course  in  con:q)utBr  net¬ 
works  were  given  die  task  of  applying  die  tool  to  a  design  {nxiblem  and  dien  evaluating  the 
effectiveness  of  the  software.  An  evaluation  form  was  distributed  to  each  student 


Scale  Factor 

Figure  10:  Comparison  with  COMNET  II.5 


along  with  the  problem.  The  students  were  graded  on  how  weU  the  tool  was  applied  to  the 
exercise,  thus  encouraging  a  serious  effort. 

Results  of  the  evaluation  along  with  a  sample  of  the  form  are  shown  in  Appendix 
C.  As  a  result  of  the  evaluation  the  following  reservations  are  presented.  In  regard  to 
quality  and  usefulness  the  tool  got  grxxl  maiks.  Almost  all  of  the  students  felt  that  the 
application  was  easy  to  leam  and  use  and  should  be  offered  as  a  learning  ttx>l  to  supplement 
the  lecture  series.  The  major  problems  were  with  crxnpatibility  issues,  specifically,  there 
was  a  wide  range  of  responses  concerning  the  requirement  for  EGA  grq)hics  and  die 
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mouse.  Intuitively,  die  likelihood  that  one  wmild  have  no  objection  to  this  requirement  is 
related  to  what  happens  to  be  the  configuration  of  the  individual's  persoiud  computer 
system.  Also,  most  students  would  rather  use  die  software  on  their  own  systems  rather 
than  the  Z-248's  in  the  laboratory  which  are  properly  configured. 

Another  perception  of  deficiency  in  the  tool  was  the  lack  of  a  capability  of  being 
able  to  copy  files  from  within  the  program  rather  than  having  to  exit,  copy  die  file,  and  then 
return.  This  feature  was  simply  overlooked  in  the  software  design  and  should  have  been 
included.  Students  also  suggested  that  the  application  provide  the  capability  to  calculate 
total  capacity  of  the  network.  This  recommendaticMi  is  probably  more  a  result  of  the  spe¬ 
cific  problem  assigned  rather  than  a  general  observation. 

Recommendations 

One  of  the  goals  as  outlined  in  the  thesis  proposal  was  the  possible  inclusion  of  an 
expert  system  that  could  evaluate  a  specific  network  routing  configuration  and  then  make 
decisions  as  to  alternate  routing  schemes.  This  feature  was  not  completed  due  to  the  lack  of 
success  in  implementing  an  effective  and  intelligent  search  algorithm.  The  attempts  that 
were  made  at  implementing  various  expert  system  techniques  were  met  with  limited  suc¬ 
cess.  The  resulting  functions  were  somewhat  unreliable  or  inconsistent  in  execution  and 
tended  to  degrade  the  overall  quality  of  the  program. 

In  the  source  code  accompanying  this  paper  a  separate  compilation  unit  entitled 
"altroute.c"  has  been  reserved  for  possible  future  development  As  of  this  writing  the 
module  has  die  capability  to  search  through  die  data  for  die  link  widi  die  highest  intensity 
and  dien  identify  all  routes  that  contain  die  link.  In  addition,  the  function  will  sum  all  of  the 
values  for  die  average  delays  of  the  links  that  make  up  each  rou  je  identified .  It  will  then 
display  each  route  label  along  widi  its  conesponding  delay  sum.  The  user  is  next  pronqited 
for  a  decision  as  to  whether  or  not  the  routing  table  is  to  be  modified.  If  the  user  responds 
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in  the  affirmative  control  is  transferred  to  the  routing  editor.  The  logical  extension  to  this 
module  would  be  to  go  back  into  the  data  base  and  find  an  alternate  route  fcH*  the  (xie  caus¬ 
ing  the  largest  degree  of  aggregate  delay. 

Users  all  seemed  to  be  in  agreement  that  the  graphical  interface  was  a  strength  of  the 
tool;  therefore,  it  is  conceivable  that  this  same  interface  be  used  for  more  sq>histicated  net¬ 
work  models  such  as  those  which  use  dynamic  routing  or  allow  for  (^)erational  overtiead 
like  propagation  delay  or  error  handling.  The  graphics  source  code  (net.c)  may  be  used 
with  little  or  no  modification  for  a  variety  of  analytical  techniqitts  that  could  be  included  in 
the  analysis  module  (analysis.c). 

In  the  near  term  some  other  modifications  are  in  order  as  a  result  of  the  in-class 
evaluation.  Most  notably  is  the  file  copy  capability  mentioned  earlier.  Also,  a  CXjA  ver¬ 
sion  could  be  developed  by  using  the  set  of  GGA  drivers  already  available  in  the  Turbo  C 
package  (in  lieu  of  the  EGAA^GA  routines)  and  then  modifying  the  pixel  coordinates  to 
allow  for  the  reduction  in  resolution. 
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AFIT/ENG  Network  Simulator 


USER’S  MANUAL  for 

AFIT/ENG  COMPUTER  NETWORK  SIMULATOR 


System  ibm  compatible  pc 

Requirements  EGA  Monitor  and  Graphics  card  with  256K 

Microsoft  Compatible  Mouse 
IBM  Graphics  Compatible  Printer 

Overvi  ew  The  simulator  Is  composed  of  three  main  modules  -  a  network 

network  editor,  a  routing  editor,  and  an  analyzer.  The  first  two 
require  the  EGA  graphics  and  mouse,  while  the  analyzer  will  run 
on  Just  about  any  PC  Compatible.  The  basic  flow  of  the  program  is 
to  first  construct  a  network  and  assign  link  capacities.  After  a 
network  has  been  defined  the  user  calls  up  the  routing  editor  to 
select  routes  and  enter  appropriate  traffic  levels.  With  the 
network  and  routes  defined  in  the  first  two  modules  the  user  can 
assign  a  packet  size  and  run  an  analysis.  The  analysis  1s  based  on 
an  M/M/ 1  queue  for  packet  arrivals.  Results  Include  traffic, 
average  delay,  optimal  capacity  assignment,  and  traffic  Intensity 
for  each  link  as  well  as  average  delay  for  the  network.  Both  the 
drawing  and  the  analysis  results  can  be  saved  and/or  printed. 

Three  different  disk  files  are  created  when  drawing  a  network: 
■■.nde",  ".Ink",  and  ".rte",  corresponding  to  the  sets  of  nodes,  links, 
and  routes.  Also  the  analysis  results  can  be  saved  In  a  ".txt"  file 
for  viewing  and  printing.  A  saved  drawing  must  contain  both  nodes 
and  links  or  the  analyzer  will  not  recognize  It  when  an  attempt  Is 
made  to  open  It  again.  The  routing  table  and  analysis  results  are 
optional. 
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Theoretical^,  the  simulator  will  allow  networks  of  any  size 
but  as  a  practical  matter  the  screen  size  will  limit  the  amount  of 
graphical  data.  The  software  has  been  tested  with  as  many  as  66 
nodes  and  120  links  with  no  problems. 

Getting 
Started 

First,  make  sure  that  the  following  three  files  are  In  the 
default  directory  (i.e.  you  should  be  In  the  same  directory  as  the 
flies  or  include  the  executable  files'  directory  In  a  path 
statement): 

NET.EXE  -  main  program 

E6ADMP.COM  -  E6A  printscreen  routine 

GONET.BAT  -  batch  file  that  loads  the  above  files. 

Enter  "gonet".  The  screen  print  routine  will  load  first 
followedby  the  main  routine  (Figure  1).  The  program  will  then 
prompt  for  a  filename,  which  may  either  be  a  new  or  existing  file. 
If  the  file  Is  not  found,  the  program  will  create  It.  We  will  create 
a  set  of  files  named  demo,  so  enter" demo”  (without  an  extension). 
The  next  window  (Figure  2)  will  display  several  choices.  Since 
this  is  a  new  file  enter  'V  to  create  the  network.  The  program 
will  enter  the  graphics  mode  and  enable  the  mouse  (Figure  3). 
Displayed  across  the  top  are  choices  that  are  invoked  by  locating 
the  arrow  over  a  box  and  clicking  any  mouse  button.  To  get 
started,  mouse  over  to  the  upper  left  and  click  on  the  "Node' 
button,  then  locate  the  arrow  near  the  upper  left  comer  below  the 
text  and  click.  A  rectangular  node  will  be  drawn  followed  by  a 
prompt  for  a  label.  Type  'a'.  The  node  will  be  labeled  and  the 
program  will  return  you  back  to  the  top  of  the  network  editor. 


One  of  the  basic  ideas  driving  the  design  of  this  simulator  was 
simplicity  of  use.  A  short  tutorial  which  follows  should  be  all 
that's  necessary  to  get  started. 
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r  I  Node  irTTnk  H  Save  irodete  ll  Print  il  Routell  Quit  II  Analyze  II  Replace  I 


tNETWORK  editor! 


Active  file;  demo 


Figure  3;  Network  editor 


Nov/  select  "Node"  again  and  place  a  second  node  about  2"  to  the 
right  of  node  ‘a’  -  label  this  one  'b‘. 

Now  that  we  have  two  nodes  we  can  go  ahead  and  connect  them  with 
a  link.  Select  the  "Link"  button  and  move  the  arrow  anywhere 
over  the  a'  node.  Press  and  hold  down  a  mouse  button.  With  the 
button  still  pressed,  move  the  arrow  anywhere  over  node  ’b'  and 
release  (this  Is  sometimes  referred  to  as  "dragging").  After 
releasing  the  button  you  should  see  a  line  appear  between  the  two 
nodes  and  a  prompt  on  the  topline  of  the  screen  asking  for  the  link 
capacity.  Enter  "20".  The  link  will  be  labeled  with  arrows  In 
both  directions  ^d  capacities  In  kbps  for  each  direction.  Your 
drawing  should  be  similar  to  the  following  sketch. 
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A  network  Is  constructed  using  the  above  techniques  to  place  nodes 
and  connect  them  with  links.  For  this  exercise,  we'll  add  one  more 
node  and  connect  It  to  the  others  with  simplex  links. 

Select  the  “Node"  button  and  place  another  node  'C  below  the 
first  two.  Next  construct  a  20  kbps  link  from  node  'a'  to  C  using 
the  'S'  suffix  when  entering  the  capacity  assignment.  Do  the  same 
for  the  link  from  'c'  to  'b'.  The  final  product  should  resemble  the 
one  In  the  figure. 


Having  constructed  our  sample  network  we  re  ready  to  go  on  to 
the  routing  editor.  Mouse  over  to  the  "Save"  button  at  the  top  and 
click,  then  do  the  same  for  the  "Route"  button.  The  program  will 
now  put  you  Into  the  routing  editor  with  Its  green  menu  buttons 
(Figure  4).  Let's  say  we  want  to  create  a  route  from  node'a'  to 
node  'b'  using  links  "ac"  and  "cb".  Select  the  "Create  a  Route" 
button  on  the  upper  left.  To  create  the  route  click  on  the  nodes 
along  the  route  In  order.  In  this  case,  a-c-b.  The  nodes  and  links 
will  be  highlighted  as  they  are  selected.  After  clicking  on  node  'b' 
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mouse  up  to  the  large  "Stop”  bar  and  click.  You'll  be  asked  to  enter 
forward  traffic  In  PACKETS  PER  SECOND  rather  than  kbps.  Enter 
'2'.  The  editor  will  next  ask  you  for  reverse  traffic  which  should 
be  none,  so  simply  press  the  enter  key.  The  route  Is  now  defined; 
to  see  the  routing  table  click  on  the  "View"  button.  Our  simple 
routing  table  will  be  displayed  showing  the  route  and  Its  traffic. 
Click  any  button  to  return  to  the  editor. 


Next  click  on  the  "Analyze"  button  to  perform  an  analysis  of  the 
newly  created  network.  The  routing  editor  will  prompt  you  to 
save  the  routing  table.  Default  Is  "yes"  so  hit  any  key  except  'n'. 
The  analyzer  will  now  load  and  prompt  for  packet  size  -  we  ll  use 
800.  Note  that  the  packet  size  is  entered  In  BITS.  After  entering 
the  packet  size  the  program  will  display  the  results  of  the 
analysis.  Along  the  bottom  is  displayed  a  series  of  commands 
which  are  explained  by  typing  'H'.  Note  that  the  optimal  cap 
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column  displays  all  zeroes  until  the  user  elects  to  calculate  the 
optimal  capacity  assignments  based  on  desired  delay.  Your  results 
should  be  the  sane  as  those  shown  here. 


Arr  Rate 

Capacity 

Capacity 

Delay 

Traffic 

Optimal 

1 

Line 

(pkts/s) 

(kbps) 

(pkts/s) 

(ms) 

Intensity 

Cap(kbps) 

1 

ac 

2.00 

20 

25.00 

43.478 

0.08000 

0.00 

2 

cb 

2.00 

20 

25.00 

43.478 

0.08000 

0.00 

To  exit  the  analyzer  type  ’q'  and  answer  the  prompts.  Note  that 
any  changes  to  capacity  assignments  will  update  the  .Ink  files  and 
be  automatically  reflected  In  the  drawing  if  you  elect  to  save  the 
table.  If  you  wish  to  save  the  results  of  the  analysis  for  later 
viewing  or  printing,  type  y  at  the  "Write  table  to  text  file?" 
prompt. 


This  completes  the  tutorial. 
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1 

!  Reference 

I  Section 

Proaram 

I  SlruLture 


! 


The  analyzer  has  one  executive  and  three  functional 
elements.  The  network  analysis  may  be  Interrupted  at  any 
stage  and  any  work  In  progress  may  be  saved. 


Main  Menu 

Network 

Routing 

Network 

Editor 

Editor 

Analyzer 

The  network  editor  Is  where  the  model  Is  originated  and 
where  the  original  capacity  assignments  for  all  links  are 
made.  Any  addition  or  removal  of  a  node  or  link  must  be 
done  here.  After  a  network  has  been  drawn  and  all 
capacities  assigned,  the  routing  editor  Is  selected  from  the 
row  of  selection  buttons  at  the  top  of  the  network  editor 
screen.  The  user  may  move  freely  back  and  forth  between 
the  network  editor  and  routing  editor. 

The  routing  editor  builds  and  displays  the  routing  table. 
Routes  are  determined  by  using  the  mouse  to  select  the 
nodes  that  define  the  route.  The  current  routing  table  can 
be  viewed  quickly  by  selecting  the  '  VIEW  command,  (The 
routing  table  screen  stays  residerit  in  memory). 

Finally,  the  analysis  module  uses  the  sets  of  nodes,  links, 
and  routes  to  calculate  the  parameters  of  the  network.  The 
module  provides  on-screen  help  to  explain  the  various 
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Tod  Menu 


Network  Editor 

Node 


commands.  All  of  the  parameters  are  displayed  In  a  table 
that  can  be  saved  to  a  text  file  If  desired. 

The  rest  of  this  manual  will  explain  the  various  commands 
and  options  available  In  each  of  the  three  modules  - 
network  (drawing)  editor,  routing  editor,  and  analyzer,  as 
well  as  the  opening  menu.  (The  terms  Drawing  Editor  and 
Network  Editor  are  Interchangeable). 


Displays  choices.  To  begin  building  a  network  or  to  edit  an 
existing  drawing,  type  ‘  T'  followed  by  <Enter>.  To  create 
or  edit  a  routing  table  type  "T  followed  by  <Enter>.  To 
run  an  analysis  type  ''3  <Enter>".  Note  that  routing  and 
analysis  are  impossible  without  first  creating  a  network 
using  the  network  editor. 


Creates  and  labels  a  node.  Node  label  must  be  a  single, 
unique,  printable  character.  Action  may  be  canceled  by 
clicking  on  the  “Cancel”  button  at  the  top  of  the  screen. 
Note  that  the  program  restricts  the  mouse  movement  such 
that  a  node  can  be  placed  only  where  It  will  be  totally 
displayed.  A  node  appears  on  the  screen  as  a  rectancle 
filled  with  blue  slashes.  User  is  prompted  for  a  label 
which  Is  displayed  In  the  center  of  the  node.  Control  is 
then  returned  to  the  network  editor  main  menu.  The 
collection  of  nodes  Is  saved  as  a  nde  file. 
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Link 


Save 


Delete 


Delete 


Creates  and  assigns  capacity  In  kbps  to  a  link.  Link  is 
created  by  locating  arrow  over  the  node  of  origin  and  then 
clicking  and  dragging  the  mouse  over  to  the  destination  node 
where  the  mouse  button  Is  released.  Capacity  assignment 
should  be  a  numerical  value  with  full-duplex  being  the 
default  condition.  A  simplex  node  Is  designated  by  the 
addition  of  an  ‘S’  suffix  to  the  capacity  entry.  Only  one  link 
In  either  direction  Is  allowed.  All  links  for  a  particular 
network  are  saved  as  a  .Ink  file. 

Saves  the  drawing  as  nde  and  .Ink  files.  If  you  decide  to 
quit  but  forget  to  save  the  drawing  the  editor  will  ask 
whether  or  not  to  save  changes  (If  editing  was  done). 

Use  to  delete  a  network  element.  When  selected  the  editor 
displays  two  choices  corresponding  to  either  deleting  a  node 
or  deleting  a  link.  Both  are  discussed  below: 

node  Point  to  the  node  to  delete  and  click.  All  connecting  links 

will  automatically  be  eliminated.  If  an  attempt  is  made  to 
delete  a  node  that  is  used  by  a  route  the  program  will 
disallow  the  action  and  inform  you  that  a  route  Is  using  that 
node.  Before  deleting  the  node  that  Is  In  use  you  must  first 
use  the  routing  editor  to  delete  all  routes  that  use  the  node. 
To  view  the  current  list  of  routes,  select  first  the  "ROUTE' 
button  from  the  network  editor  and  once  In  the  routing 
editor,  select  "VIEW". 
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Delete  a 


Print 


link  Type  the  labels  of  the  terminating  nodes  in  proper  order. 

If  the  link  Is  not  presently  In  use  by  a  route,  the  editor 
will  delete  the  link  connecting  the  two  nodes.  For  example, 
to  delete  the  link  connecting  nodes  ‘a’  and  'b',  type  “ab"'.  No 
<Enter>  keypress  is  needed. 

If  an  attempt  Is  made  to  delete  a  link  that  Is  used  in  the 
routing  table  the  program  will  disallow  the  action  and  alert 
the  user  that  the  link  Is  In  use.  All  routes  that  use  the  link 
must  first  be  deleted  with  the  routing  editor  before  the 
link  can  be  deleted. 

Note:  program  will  not  delete  a  link  ac  node  that  lias  been 

included  In  a  route  -  the  corresponding  route  must 
first  be  deleted  using  the  routing  editor. 

Prints  the  displayed  network.  When  selected,  the  routine 
deletes  the  top  menu  and  waits  for  a  <Sh1ft><Prtsc>  key 
combination.  For  high  quality  printout,  type  'h' 
Immediately  after  <Sh1ft><Prtsc>.  It  may  be  necessary  to 
use  the  12  CPI  (elite)  setting  on  printers  that  are  not 
100^  IBM  graphics  compatible.  Pressing  the  <ESCAPE> 
key  will  abort  the  print. 

This  option  requires  that  the  EGADMP.COM  program  be 
loaded  and  resident.  To  print  analysis  results,  use  the  Save 
command  from  the  Analyzer  module  to  save  the  results  as  a 
text  file.  The  text  file  can  be  printed  using  the  DOS  "PRINT 
<f11ename>"  or  "COPY  <f11ename>  PRN"  command. 
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Route 

Quit 

Analyze 

Replace 


Routing  Editor 

Create  a  Route 


Invokes  the  routing  editor.  The  routing  editor  uses  the 
drawing  created  by  the  network  editor  to  develop  a  routing 
table.  It  Is  readily  distinguishable  by  the  green  menu 
buttons.  Changes  made  In  the  network  editor  will  be 
retained  and  may  be  saved  to  disk  later  If  desired. 

Quits  to  the  Topmenu.  if  changes  have  been  made  either  to 
the  routing  or  the  drawing,  user  will  be  queried  whether 
or  not  to  save  them.  All  changes  may  be  discarded  with  a 
negative  response. 

Invokes  the  analyzer.  Program  will  ask  If  changes  made 
are  to  be  saved.  Default  is  yes.  Also  prompts  for  packet 
size  If  norte  has  been  entered.  The  packet  size  is  a  mean 
value  (exponentially  distributed)  in  bits. 

Allows  deletion  and  construction  of  a  link  without  the 
Intermediate  return  to  the  top  menu  of  the  editor.  Comes 
In  handy  during  network  modifications. 


Creates  a  route  by  successive  selection  of  nodes  along  the 
route,  beginning  with  the  node  of  origin.  As  nodes  are 
selected  with  the  mouse,  the  network  elements  are 
highlighted  in  yellow  to  provide  a  trail.  User  Is  prompted 
for  forward  and  return  traffic  in  packets  per  second. 
Clicking  on  the  "Stop"  bar  terminates  selection  of  nodes  or 
aborts  If  no  nodes  have  been  selected.  Route  Is 
automatically  added  to  the  routing  table  and  may  be 
observed  by  selecting  the  ‘  VIEW”  button. 


60 


AFIT/ENG  Network  Simulator 


Delete 

Save 

View 


Analyze 


Quit 

Edit  Dwg 


A  route  may  t>e  defined  over  one  or  more  links  that  do  not 
exist.  The  analysis  portion  of  the  application  will  catch 
this  and  warn  of  the  errors,  after  which  It  will 
automatically  place  the  user  In  the  network  editor  to  add 
the  missing  links  If  desired. 

Shows  the  current  routing  table  and  prompts  for  entry  of  a 
route  to  delete.  If  there  is  no  match,  no  action  will  be 
taken. 

Saves  the  routing  table  as  .rte  file. 

Displays  the  current  routing  table.  Will  display  up  to  81 
routes.  This  display  remains  resident  1n  memory  and  Is 
quickly  called  up.  This  makes  the  routing  and  verification 
process  smooth  and  less  frustrating  than  If  the  screen  were 
redrawn  each  time. 

Invokes  the  analyzer  if  there  are  no  disagreements  between 
the  routing  table  and  network.  Will  prompt  user  for 
packet  size  If  value  has  not  already  been  entered.  The 
packet  size  Is  entered  as  bits  per  packet.  If  the  routing 
table  and  drawing  disagree  the  analyzer  will  sound  the 
beeper  and  list  the  routes  that  are  missing  data  links. 

Quits  to  Topmenu.  Will  prompt  for  saving  of  any  edits  to 
the  routing  table  or  the  drawing. 

Invokes  the  network  editor.  The  network  and  routing 
editors  are  freely  switched  from  one  to  the  other. 
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Anaiv7<^r  The  commands  for  the  analyzer  are  displayed  at  the  bottom 

of  the  screen.  Help  can  be  displayed  by  typing  'h'. 

P  Displays  current  packetsize  In  BITS.  New  packet  size  can 

be  entered  if  desired.  Typing  only  <Enter>  puts  you  back  In 
the  analyzer  v/lthout  modifying  the  packet  size.  Changing 
the  packet  size  will  automatically  cause  recalculation  of 
the  network  parameters. 

D  Views  the  average  delay  for  the  entire  network  in 

milliseconds.  This  value  can  later  be  modified  as  a  delay 
coi.jt  ^inL  for  the  network  In  order  to  find  optimal 
capacity  assignment  (Refer  to  "0"  command). 

C  Enables  the  revision  of  any  link  capacity  shown  In  the 

analysis  table.  If  the  analysis  results  are  saved,  the  new 
capaclty(s)  will  be  automatically  entered  Into  the  drawing. 
Typing  <Enter>  twice  will  abort  the  command  and  will  not 
affect  the  analysis. 

0  Calculate  optimal  capacity  assignment  based  on  desired 

delay  In  milliseconds.  The  optimal  capacity  assignments 
will  be  displayed  In  the  right-most  column.  Optimal 
capacity  assignments  are  zero  by  default  until  a  delay 
constraint  Is  entered  using  this  command. 

R  Replaces  ALL  capacity  assignments  with  the  current  values 

shown  In  the  Optimal  Cap(kbps)  column.  If  the  current 
analysis  Is  saved,  the  drawing  will  be  updated  to  show  all  of 
the  new  capacities;  therefore,  use  with  caution.  It's 
probably  a  good  Idea  to  keep  a  backup  copy  of  any  network 
drawing  before  experimenting  with  It. 
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A  Alternate  routing,  The  critical  link  will  be  displayed  along 

with  the  existing  routes  that  contain  the  link.  It  also 
prompts  for  modification  of  the  routing  table.  If  y  Is 
typed,  the  routing  editor  Is  Invoked. 

S  Save  the  results  of  the  current  analysis.  The  drawing  will 

be  updated  to  reflect  any  change  In  capacity  assignments. 
Also  prompts  for  storage  of  the  results  as  a  text  file.  The 
text  file  can  be  printed  using  the  "PRINT  <f11ename>"  or 
"COPY  <f11ename>  PRN'  commands  from  DOS  or  may  be 
copied  Into  a  word  processor. 

Q  Quit  toTopmenu. 
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Formulas: 

y.  :  traffic  for  route  i  (packets/sec) 

•j-  :  average  packet  size  (bits/pkt)  for  network 

C  , :  link  capacity  in  kpbs  (kilobits  per  second) 

|aC  :  service  rate  (packets/sec) 

X  ,  :  average  arrival  rate  (packets/sec) for  link  i 
(Sum  of  all  traffic  y  using  the  link) 


d  :  cost  per  kbps  (Normalized  to  1 ). 


I  "  -  :  average  delay  for  link  i 

m 

1=  Xy,  :  sum  of  all  traffic  on  the  net 


m 

X=  5^X,  :  sum  of  all  link  arrival  rates 

1-1 

X 

p.  =  — -  :  traffic  intensity  for  link  i 


T 


mean  packet  delay  for  network 


C 


1  j^i  J 


yT 


optimal  capacity 
:  for  link  i  based  on 
delay  constraint  T 
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Appendix  B 
Equivalence  Classes 


External 

Condition 

VaM 

Equivalence  Gasses 

Invalid 

Equivalence  Passes 

Opening  menu:  Hlename 

1  -8  Characters!  1), 

No  file  extension(3) 
<Enter>(5) 

>8  Characters(2) 

Hie  extensi(Mi(4) 

Viewdir  Filename 

1-8  Characters(6) 

No  file  extension(9) 

<1  Character!?),  >9  Char(8) 
File  extension!  10) 

Topmenu: 

Menu  selection 

'2*(12).  '3’(13). 
•4'(15).  or  ■5*(16) 

Notin  {1  ..  5)  !14) 

Drawing  Editor  Module 


External 

Condition 

Valid 

Equivalence  Gasses 

Invalid 

Equivalence  Gasses 

Drawnet; 

Mouse  button  pressed 

Active  legiOTfl?) 
!"Hotspot") 

Inactive  region!  18) 

Drawnode:  Mouse  down 

Drawing  area!19) 
Canceiai) 

Outside  drawing  area!20) 
Keypress!22) 

Drawnode:  Nodelabel 

Unique  printable 
chanicter!24) 

Non-printing  chaiacter!23) 
Non-unique  charactet!2S) 

Drawlink:  Draw  a  link 

Cancel!26) 

Connect  two  nodes 
w/o  overwriting 
existing  link!29) 

Not  connecting  2  nodes!27) 
Overwrite  existing  link!28) 
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Drawlink:  Linkcapacity 

1-6  characters  FDX(30) 
1-6  characters  SPX(32) 

>  6  Qianicters(31) 

<  1  Character<33) 

FDX  over  existing  SPX(34) 
Non-jninting  Characters(3S) 

Save  Command 

No  editting  done(36) 

Save  with  changes(38) 

Null  database(37) 

Delete  Command: 

Delete  a  node 

Select  node(39) 

Cancel(41) 

Keypress(40) 

Select  blank  space(42) 

Delete  Command: 

Delete  a  link 

Displayed  link  symbol(43) 

<  2  Characters(44) 

Mouse  down(4S) 

Non-existent  link(46) 

Print 

<Shift><Prtsc>(47) 
<ShiftxPrtsc>  &  ’h’(49) 
Any  other  key(50) 

Mouse  down(48) 

Quit- 

Save  drawing  prompt 

'y’(51).  'n’(52).Not  y  or 

•n’(53) 

Replace 

Valid  link  symbol(54) 
<Esc>(56) 

Same  as  drawlink(S7) 

Arbitrary  string(55) 

Other  non-printing 
character(S8) 

Routing  Editor  Module 


External  Valid  Invalid 

Condition  Equivalence  Gasses  Equivalence  Passes 


Routing  editor 


Valid  Selection(59) 


Keypress(60) 
Invalid  selection(61 


Create  a  Route 

Sequence  of  nodes(62) 

Stop  selection(64) 

Selections  outside  nodes(63) 
Keypress(6S) 

Delete 

<Entei>(66) 

Valid  route  syinbol(68) 

Other  ncm-print  char(67) 
Nonexistent  toute(69) 

Save 

Changes(70) 

Null  routing  database(7 1 ) 

No  changes  made(72) 

View 

View  routing  table(72a) 

Quit:  saves  changes? 

y(73) ,  n(74),Not  y  or  n(75) 

Analysis  Module 

External 

CQDijiQgO 

Valid 

Equivalence  Passes 

Invalid 

Equivalence  Passes 

Analyze:  Bits  per  packet 

Pos  floating  point 
number(77) 

Non  positive  floating  pt(76) 
Non-numeric  entry  (7  8) 

Analyze:  menu  selection 

Displayed  selection5(79) 

Non-displayed  char  (80) 

Pktsize  window  prompt 

Pos  floating  point(81) 
<Enter>(83) 

Non  positive  floating  pt(82) 
Non-numeric  entry(84) 

Changccap: 

Linklabel 

Capacity  Assignment 

Displayed  link(85) 

1-6  digits(87) 

Arbitrary  string(86) 

<1(88),  >6  digits(89), 
Non-numeric(90) 

Optimal  capacity:  delay 

>0  and  <999999(92) 

<0(93),  >999999(94) 
Non-numerical(9S) 

Replace  capacities  with  opt 

y(96) ,  n(97) 

Noty  orn(98) 

68 


Alternate  routing 

y(99) ,  n(100),Not  y  or  n(lOl) 

Save:  Write  to  text  file 

y  (102),  n(103)J4ot  y  rar  n(104) 

Quit:  Save  table? 

y  (105),  n(106)a^ot  y  or  n(107) 

Help  Any  key(108) 

Any  key(108) 


Test  Case 

m. 


JSSk 

iocui 


Drawing  editor 


Equivalence 

Passes  Cfiycred 


A-a 

Drawnode:  Cancel  17.  19.  21,  24.  26.  29,  30,  32, 

36, 

38, 

-b 

Drawnode:  valid  area  39,  41 ,  43,  47,  49,  50,  54,  56, 

57, 

51 

-c 
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Appendix  C:  Software  Evaluation  Survey  Results 

This  survey  will  be  used  to  evaluate  the  operation  of  the  AFTT/ENG  Computer  Netwcn-k 
Simulator.  Please  choose  one  of  the  Hve  possibilities  and  feel  free  to  add  comments  below 
your  response.  There  are  some  questions  at  the  end  and  some  space  for  any  additional 
comments.  Thanks  for  participating. 

1  2  3  4  5 

Strongly  Disagree  Disagree  Neutral  Agree  Strongly  Agree 

1 .  Most  CAD  packages  that  I've  had  experience  with  are  somewhat  difficult  or  awkward  to 
learn  and  use. 

□  □  □  □  □ 

12  3  4  5 

Mean  =  3.27;  Std  Dev  =  0.704;  Low  s  2;  High  =  4-  _ 

2.  The  mouse  is  better  suited  as  a  drawing  device  than  the  keyboard. 

□  □  □  □  □ 

12  3  4  5 

Mean  =  4.73;  Std  Dev  =  0.458;  Low  s  4;  High  =  5.  _  ^ _ 

3.  For  most  CAD  programs  that  I've  used  in  the  past  but  don't  use  all  the  time, 

"relearning"  the  commands  and  program  flow  takes  too  long. 

□  □  □  □  □ 

12  3  4  5 


Mean  =  3.13;  Std ^v  =  0.834;  Low  =  2;  High  a  5.  _ 

4.  Getting  started.  Hits  network  simulator  has  a  reasonably  short  learning  curve. 

□  □  □  □  □ 

12  3  4  5 

Mean  =  4.87;  Std  Dev  =  0,352;  High  =  5.  _ ^ 

5.  On-screen  help.  The  amount  and  quality  oi  on-screen  help  for  the  simulator  is 
adequate. 

□  □  □  □  □ 

12  3  4  5 

Mean  =  4-33;  Std  Dev  =  Low  =  3;  High  s  5.  _ 

6.  User  friendliness  Overall  the  simulator  has  a  wmewhat  intuitive  interface. 

□  □  □  □  □ 

12  3  4  5 

Mean  =  4.40;  Std  Dev  =  0.632;  Low  s  3;  High  =  5. _ 
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7.  Speed.  The  simulator  seems  to  execute  all  of  its  commands  quickly  enough. 

n  □  □  □  □ 

12  3  4  5 

Mean  =  Std  Dev  =  0.834;  Low  =  2;  High  =  5. _ 

8.  Portability.  The  requirements  ^or  and  a  n^se  arc  reasonable. 

□  □  □  □  □ 

12  3  4  5 

Mean  =  3.00;  Std  Dev  =  1»13;  Low  =  1;  High  =  5. _  _ 

9.  Usefulness.  The  simulator  helped  me  understand  the  operation  and  performance 
characteristics  of  a  packet-switch^  network. 

□  □  □  □ 

12  3  4  5 

Mean  =  4.20;  Std  Dev  -  0.561;  Low  =  3;  High  =  5.  _ 

10.  This  software  can  be  of  value  to  an  introductory  course  in  computer  networks. 

□  □  □  □  □ 

12  3  4  5 

Mean  =  4.47;  Std  Dev  =  0.640;  Low  =  3;  High  =  S. _ 


Questions: 

1.  What  improvements  do  you  think  are  needed?  What  additional  feature(s)  should  be 
added? 

•  CGA  Capability  (4  responses) 

•  Keyboard  only  capability  (2) 

•  Ability  to  save  data  to  another  file  without  leaving  program  (7) 

•  Ability  to  calculate  total  network  capacity  (2) 

2.  Did  you  uncover  any  major  bug(s)  in  the  software?  If  so,  what? 

•  Incapability  with  a  certain  brand  of  third  party  graphics  board  with  enhanced 
EGA  •  640  by  480  pixels  (1) 

•  Problems  when  deleting  all  elements  in  a  file  -  probably  got  a  null  pointer 
assignment  (1) 

3.  Any  general  comments? 

•  Mostly  positive.  Negative  comments  were  extensions  of  responses  given  in 
Question  #1  above. 
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